14:01:11 <enikanorov_> #startmeeting neutron lbaas
14:01:12 <openstack> Meeting started Thu Jan 30 14:01:11 2014 UTC and is due to finish in 60 minutes.  The chair is enikanorov_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:15 <openstack> The meeting name has been set to 'neutron_lbaas'
14:02:08 <obondarev> Hi!
14:02:13 <s3wong> Hello
14:02:17 <enikanorov_> #topic announcements
14:02:22 <enikanorov_> hi s3wong
14:02:27 <enikanorov_> we have feature proposal deadline which is 18 of Feb
14:02:32 <evgenyf> Hi
14:02:53 <enikanorov_> anything we plan to land in I should be pushed to gerrit prior to 18 feb
14:04:02 <vjay> Ok. My apologies for ignorance. how is ssl and L7 looking.
14:04:18 <enikanorov_> yep, lets discuss features
14:04:46 <enikanorov_> so per previous meeting decision, we need backed support of the new portions of API that we're going to add
14:04:51 <enikanorov_> e.g. L7 and SSL
14:05:13 <enikanorov_> #topic features discussion
14:05:41 <enikanorov_> currently L7 and SSL extensions are on review and require some work (fixing reviewers comments, etc)
14:06:09 <enikanorov_> Oleg is going to work on L7 for haproxy while I'm going to work on adding SSL to haproxy (via stunnel)
14:06:41 <enikanorov_> in both cases our work is depends on corresponding extension patches (so we can do end-to-end testing)
14:07:11 <obondarev> L7 also depends on loadbalancer instance patch I believe
14:07:36 <evgenyf> I have more commets to address in SSL, some were addressed in the last patch
14:07:43 <enikanorov_> right. that would be a requirement for haproxy to pick l7 up
14:08:04 <obondarev> yes
14:08:11 <enikanorov_> regarding SSL there are a few things that we need to consider
14:08:19 <enikanorov_> first of all, server-agent communication
14:08:31 <evgenyf> right, association resource
14:08:52 <enikanorov_> I've started corresponding thread on ML. Only russellb replied so far.
14:09:06 <enikanorov_> Personally I like the idea of secure messaging
14:09:29 <enikanorov_> especially because it doesn't require anything additional from the code
14:09:52 <vjay> a related question, what is the call on certs and keys storage? is it using the babican service?
14:09:57 <enikanorov_> so I think that will be the approach I will follow
14:10:13 <enikanorov_> vjay: not yet.
14:10:30 <enikanorov_> vjay: i think we're going to use cert attributes as transient for now
14:10:49 <enikanorov_> we decided that neutron db is not going to be a storage for certs
14:11:16 <enikanorov_> so that brings up some difficulties in managing ssl-enabled vips
14:11:37 <vjay> where are these discussions/decisions happening?
14:11:40 <enikanorov_> (I'm talking about haproxy implementation right now)
14:12:07 <enikanorov_> vjay: we've discussed that on the previous meeting
14:12:22 <vjay> ok. may be i missed.
14:12:40 <enikanorov_> also there is quite old thread on ML about whether to store certificates in db
14:13:04 <vjay> i remember that, but in the original thread the final discussion was undecided.
14:13:04 <enikanorov_> and as far as i recall, the opinions were different on the matter
14:13:22 <vjay> no conclusion/concensus on the db store was reached
14:13:27 <vjay> nor transient
14:13:38 <enikanorov_> right. Mark has some project-wise security concerns on storing certs in db.
14:13:42 <vjay> because in case of transient we cannot apply back the config
14:13:52 <vjay> ok
14:13:55 <enikanorov_> yes, that's the problem
14:14:33 <enikanorov_> we only can pass cert  once, in case we move configuration, or restart the agent, certs could be lost
14:15:13 <enikanorov_> 'lost' logically, i mean. so in order to bring vip up, tenant will need to provide certificates once again
14:15:25 <vjay> ok
14:15:39 <vjay> how will that be communicated to client
14:15:40 <enikanorov_> and sad thing is, that looking at ssl extension i don't see how it can be done
14:15:57 <evgenyf> we will have to ask for private key of certs every time association issued
14:16:15 <enikanorov_> that is a good question that we can't notify client, actually
14:16:27 <enikanorov_> client can monitor vip
14:16:35 <enikanorov_> status of vip
14:16:52 <obondarev> sorry, which client?
14:16:54 <enikanorov_> we only can put it into down state indicating that certificate is required
14:17:01 <obondarev> do you mean user?
14:17:05 <enikanorov_> obondarev:vjay meant user
14:17:12 <vjay> sorry, yes tenant/user
14:17:17 <obondarev> ok, thanks
14:18:30 <vjay> apologiesso will this extension be marked experimental or will the APIs be part of LBaaS plugin?
14:18:38 <iwamoto> can Marconi be used for notification?
14:18:53 <enikanorov_> vjay: we also decided that ssl is a part of core lbaas api
14:19:05 <vjay> ok.
14:19:06 <enikanorov_> l7 and ssl are core features
14:19:16 <enikanorov_> that's why we need solid design for that
14:19:26 <vjay> ok
14:20:06 <enikanorov_> evgenyf: could you think of how we can propose single workflow regardless of whether we store certs in db or not?
14:20:21 <enikanorov_> or at least, similar workflow
14:20:47 <vjay> should db even be considered? we can think of transient and babican right?
14:21:23 <samuelbercovici> barbican is not yet even in incubation.
14:21:31 <enikanorov_> right, but the API should be the same regardless of how we store certs
14:21:42 <samuelbercovici> the vote on this is going to happen in a week or two
14:22:46 <samuelbercovici> enikanorov_:the work with barbican should add a few more options to pass the certificates
14:23:34 <evgenyf> enikanorov_:In case the private is transient it should be taken from the request, or if persistent, take from the DB. if persistent, private may be None in request
14:23:36 <vjay> sam: it will be good if the wiki can be updated.
14:24:38 <evgenyf> I will update the WIKI with last decisions
14:24:51 <enikanorov_> evgenyf: ok
14:25:53 <vjay> ok. it will be good if we know how using barbican later will affect the apis or workflow.
14:26:07 <samuelbercovici> vjay: this is still unclear
14:27:00 <enikanorov_> so the question now is that ssl extension and db proposes separate resources for certificates
14:27:11 <samuelbercovici> the planned difference is that it will not change the api, it might add passing the "certificate id" instead of the actula certificate so that the information than be pulled from barbican
14:27:21 <enikanorov_> and workflow is that we create them, and then associate with the vip
14:27:22 <vjay> ok.
14:28:07 <enikanorov_> while 'transient' is passing certificate to the vip on create/update operation
14:28:13 <enikanorov_> what do you think?
14:28:15 <samuelbercovici> but as said, i have started looking at the possible options and apis and am waiting for the babrican project to be in incubation
14:28:31 <samuelbercovici> assuming this happens we will discuss what it means to use babican
14:29:27 <evgenyf> enikanorov_:assoc. request will go with ids, and before secure store is available, with private keys too
14:30:00 <enikanorov_> yeah, that looks like the only possible way
14:30:07 <evgenyf> so no PI change is needed when we move to secure store
14:30:09 <enikanorov_> but the API looks...
14:30:11 <evgenyf> API*
14:30:48 <enikanorov_> ok
14:32:06 <vjay> ok. the approach is to pass key during vip-ssl-associate along with the certificate_id. and when a stable store is available there no requirement to pass key
14:32:24 <vjay> does that sound right?
14:33:16 <enikanorov_> vjay: yes
14:33:43 <enikanorov_> any questions on ssl?
14:33:53 <vjay> i am good, thanks!
14:34:18 <enikanorov_> ok, let's move to l7
14:34:35 <avishayb_> hi
14:34:45 <enikanorov_> it seems that it has less global problems to resolve
14:34:50 <avishayb_> work in progress..
14:35:11 <avishayb_> need to sync the wiki with the real impl - do that next week
14:35:14 <enikanorov_> so obondarev is looking now into adopting l7 to haproxy via acls
14:35:33 <obondarev> yeah
14:35:46 <enikanorov_> after discussion with  obondarev we found out that we need lb instance in order to proceed with haproxy adoption
14:36:02 <enikanorov_> since multiple pools don't fit into current architecture
14:36:06 <obondarev> but the first step is still to adopt loadbalancer instance approach to haproxy driver
14:36:28 <vjay> any reason for lb instance checkin delay?
14:36:38 <obondarev> so I'm working on that patch now
14:36:48 <samuelbercovici> can you explain what is the chalenge to do so without lb instance?
14:37:02 <obondarev> sure
14:37:31 <obondarev> without lb instance we have only one pool with only one vip
14:38:01 <obondarev> so there is nothing l7 rools can actually swirch
14:38:08 <obondarev> rules*
14:38:29 <enikanorov_> not just that, currently whole haproxy configuration is stored under statepath/pool-id
14:38:46 <enikanorov_> also, scheduling works in such way that it binds pool to an agent
14:39:03 <enikanorov_> but we want all that multiple pools on one agent
14:39:16 <enikanorov_> handled by 1 haproxy loadbalancer
14:39:20 <samuelbercovici> obondarev: if you create a 2nd pool and associate to a VIP which is already associated to the default pool (as it must), the info can then be sent to the appropriate ga proxy
14:39:38 <samuelbercovici> ga==ha
14:39:57 <obondarev> we can't associate two pools to one vip right now
14:40:00 <enikanorov_> thats one of the complications that we tried to avoid with lb instance
14:40:22 <enikanorov_> without lb instance we have configuration graph we need to traverse
14:40:29 <enikanorov_> instead of configuration tree
14:41:30 <samuelbercovici> enikanorov_: this is basicaly pool2-->association-->vip-->default_pool
14:41:47 <enikanorov_> yes, it is
14:42:00 <enikanorov_> and that what we don't want to traverse
14:42:58 <samuelbercovici> so the change in the model is to do 1 traversal instead of 3?
14:43:23 <enikanorov_> the change is that you create new pool to already-scheduler lb instance
14:43:34 <enikanorov_> *scheduled
14:43:42 <obondarev> since both loadbalancer instance and l7 rules are decided to be core features I dont's see the reason avoiding dependency between them
14:43:52 <obondarev> as this dependency is quite natural
14:44:04 <vjay> #agreed
14:44:05 <obondarev> and makes things clear
14:44:09 <vjay> enikanorov_: is there anything blocking loadbalancer instance like design or backward compatibility or anything else? Or is it just time before core reviewers finish the review?
14:44:21 <obondarev> both in code and logically
14:44:49 <enikanorov_> enikanorov: mostly gate failures blocking everything right now. The coments on review are minor, also new API is backward-compatible
14:44:59 <enikanorov_> vjay:
14:45:02 <enikanorov_> sorry :)
14:45:04 <vjay> ok
14:45:17 <enikanorov_> so core reviewers are busy with gates
14:45:28 <enikanorov_> with fixing gate failures I mean
14:45:36 <vjay> got it
14:47:04 <obondarev> avishayb_: the new patch set seems to fail tests
14:47:26 <avishayb_> yes - I know
14:47:27 <vjay> Sam: Same is the case with NetScalers as well. Pools are sent to a device immediately when it is created. Two separate pools might landup in 2 separate devices. If the are connect to one VIP it would be a problem. LoadBalancer instance would solve the placement more naturally.
14:47:30 <obondarev> avishayb_: and also not all comments seem to be resolved/answered
14:48:07 <avishayb_> I am aware to that
14:48:26 <enikanorov_> vjay: exactly the same with haproxy right now
14:48:35 <iwamoto> I'm not sure what does the config with 2 pools and 1 vip mean
14:49:01 <enikanorov_> iwamoto:  1 pool for static images, another for dynamic pages
14:49:10 <enikanorov_> iwamoto: you balance based on uri
14:50:30 <enikanorov_> iwamoto: does it make sense?
14:50:39 <obondarev> avishayb_: ok, thank you. I have some more concerns but they are mostly minor. Anyway I'd like to check them on new patch set, where all previous conserns are resolved
14:51:15 <iwamoto> enikanorov_: ah. standard l7 rule case. i see. how about 1vip+2pools case?
14:51:35 <iwamoto> i'm still wondering we need graph traversal anyway
14:51:49 <enikanorov_> can you give an example?
14:53:43 <iwamoto> two unrelated LBs in a LB instance. eg. (pool1,pool2)-vip1, pool3-vip2
14:54:18 <samuelbercovici> iwamoto: I am not aware on any case of 1vip+2pools without l7 policies
14:54:33 <enikanorov_> and what do you mean by 'traverse'? the case you've described is possible
14:55:02 <enikanorov_> but all that vips and pools will share the same capabilities
14:55:30 <enikanorov_> for isntance, they all are handled by same provider, bind to the same device or agent
14:55:37 <enikanorov_> and stored together
14:55:47 <enikanorov_> and that is because they belong to 1 instance
14:55:58 <vjay> i have to drop off right now. thanks every one.
14:56:01 <vjay> avishayb_: looking forward for the updates in wiki
14:56:11 <enikanorov_> vjay: thanks for joining
14:56:13 <avishayb_> sue..
14:56:19 <avishayb_> *sure
14:57:58 <iwamoto> by "traverse", i mean separating pool-vip graph into disjoint groups, to write down haproxy configs or so on.
14:58:45 <enikanorov_> well, that is no different from what it would be what we'll have l7 rules
14:58:49 <samuelbercovici> enikanorov_: so the pool definition can't be shared by multiple lb instances?
14:58:53 <enikanorov_> we'll need to handle multiple backends
14:59:11 <enikanorov_> samuelbercovici: that is not planned. is it needed?
15:00:08 <samuelbercovici> enikanorov_: when the vip<-->pool relshionship will be also fixed
15:00:21 <enikanorov_> not sure, why?
15:00:40 <enikanorov_> we need to wrap up. let's move to neutron channel
15:00:44 <enikanorov_> #endmeeting