14:00:45 <enikanorov> #startmeeting Neutron LBaaS
14:00:46 <openstack> Meeting started Thu Nov 21 14:00:45 2013 UTC and is due to finish in 60 minutes.  The chair is enikanorov. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:48 <evgenyf> Hi All
14:00:50 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:57 <obondarev> Hi
14:01:26 <enikanorov> ok, lets start with announcements
14:01:47 <enikanorov> #topic announcements
14:02:07 <enikanorov> on latest neutron team meeting the following project plan was proposed:
14:02:11 <enikanorov> #link https://etherpad.openstack.org/p/NeutronIcehouseProjectPlan
14:02:43 <enikanorov> you can see that action items for our subteam go under #8
14:03:51 <enikanorov> but for the core team the first 5 items are prioritized
14:04:15 <Vijay_> "    A single VIP can have services running on different TCP ports backed by different pools." is this for L7 policy support
14:04:16 <enikanorov> others are mostly new features and are pushed to I2 and I3 milestones
14:05:14 <samuelbercovici> Vijay_, no
14:05:18 <enikanorov> Vijay_: not exactly, but it doesn't matter in this list since it is very brief and only emphasize that new lbaas features will not be on top of the core team's list for another 2 milestones at least
14:06:15 <s3wong> enikanorov: so the three items on the list for LBaaS are for icehouse-1?
14:06:31 <enikanorov> so actually any major feature published on gerrit will get -2 until issues with stability and test coverage of neutron are resolved
14:06:42 <enikanorov> s3wong: no, realistically speaking, they are for I-3
14:06:51 <enikanorov> so I'd like to set correct expectations here
14:07:40 <enikanorov> we have plenty of time to discuss, design and implement the features
14:08:02 <enikanorov> and it would be great if we could participate in ongoing qa/testing effort
14:08:33 <enikanorov> any questions on project plan?
14:08:41 <Vijay_> will there be enough time for driver changes to get in after the LBaaS plugin changes?
14:08:49 <samuelbercovici> I think this is ok, as realisticaly, SSL, L7Policy and loadbalanciner features would need some time to cook.
14:09:23 <samuelbercovici> Vijay_, what do you mean "LBaaS plugin changes"?
14:09:27 <enikanorov> Vijay_: i can't predict. But that will totally be the matter of good efforts on test coverage
14:09:55 <enikanorov> the better test we'll have, more confidence our code will make in core reviewers
14:09:59 <enikanorov> *tests
14:10:24 <iwamoto> on launchpad.net, BP lbaas-service-instance depends on BP lbaas-multiple-vips-per-pool. is this correct?
14:10:40 <enikanorov> no, actually i was going to swap the order
14:10:59 <enikanorov> since i realized that doing it in opposite order would be simpler and require less changes
14:11:37 <enikanorov> so anyway
14:11:41 <iwamoto> will lbaas-service-instance be on I-2?
14:12:00 <Vijay_> Samuel: By LBaaS plugin changes: I meant the feature changes that will be checked in as part of LBaaS plugin.
14:12:09 <enikanorov> iwamoto: I hope so, anyway i'm going to publish the implementation on gerrit in I-1
14:12:20 <enikanorov> if it gets merged in I-2 it would be greate
14:12:38 <samuelbercovici> Vijay_, ok, thanks.
14:12:41 <iwamoto> i see
14:13:24 <enikanorov> I suggest we all work on our features, publish the code and try to collaborate (by, say, rebasing our patches on one another, if they are dependent)
14:13:43 <enikanorov> but any suggestions/ideas/help on qa front will be appreciated
14:14:23 <enikanorov> ok, lets move to the next topic
14:14:35 <enikanorov> #topic QA and third party testing
14:14:48 <enikanorov> obondarev is working on tempest scenario tests for lbaas
14:14:57 <enikanorov> obondarev: would you like to give an update?
14:16:15 <obondarev> sure
14:16:20 <samuelbercovici> enikanorov: i expect that his tests will be used by all lbaas driver, correct?
14:16:22 <obondarev> sorry for the delay
14:16:28 <enikanorov> samuelbercovici: correct
14:16:34 <samuelbercovici> great!
14:16:36 <obondarev> so work in progress yet
14:16:49 <samuelbercovici> is there a bp for this?
14:16:52 <obondarev> need to finish the basic scenario test
14:16:53 <enikanorov> samuelbercovici: but that doesn't mean you should not have your driver-specific tests! :)
14:17:27 <obondarev> samuelbercovici: https://blueprints.launchpad.net/tempest/+spec/lbaas-scenario-tests
14:17:59 <obondarev> then can think on some more scenarios
14:18:21 <samuelbercovici> we will, but i think that the shared tests should cover as much as possible.
14:18:23 <enikanorov> yeah, i think some kind of simple testplan would be helpfull.
14:18:29 <enikanorov> samuelbercovici: right
14:18:57 <enikanorov> next week i'm going to dive into tempest as well
14:19:13 <enikanorov> samuelbercovici: any progress with setting up third-party testing in your lab?
14:19:19 <samuelbercovici> also, what we had in the current tests, it that the test scenario is exactly the same but the resultin checks are different for each driver
14:19:32 <samuelbercovici> this resulted that we had to copy all test and modify
14:20:07 <samuelbercovici> this also means that if something is modified in the test, it needs to be copied to all drivers
14:20:18 <obondarev> samuelbercovici: which tests do you mean as current?
14:20:32 <samuelbercovici> it would be nice if we can find a way to reuse the work of oleg without copy
14:20:55 <samuelbercovici> i mean the unit tests
14:21:27 <obondarev> this is a bit different topic I guess
14:21:50 <obondarev> as we're now discussing tempest tests
14:22:03 <enikanorov> samuelbercovici: so what's with integrating with smokestack?
14:22:21 <avishayb> About the temest - we are currently try to see what it takes. hope to have somethin until Icehouse 1
14:22:27 <samuelbercovici> obondarev: i understnad. just wishing the wokr you do will be reusable, not like the ut.
14:22:55 <obondarev> samuelbercovici: yeah
14:23:07 <enikanorov> the uts are really different because the way driver communicase requires different mocks at least
14:23:16 <enikanorov> *communicates
14:24:42 <samuelbercovici> ok. i think that after you commit ur 1st code we can discuss further
14:25:06 <enikanorov> in fact tempest already have API tests for lbaas
14:25:14 <enikanorov> which in fact test basic operations
14:25:29 <enikanorov> it's enough to test how integration with smoke stack could work
14:26:05 <avishayb> OK - I will look at it soon
14:26:49 <enikanorov> any questions on testing?
14:28:01 <enikanorov> ok, lets move on
14:28:09 <enikanorov> #topic feature discussion
14:28:28 <enikanorov> #topic features discussion
14:28:40 <enikanorov> I'll start with loadbalancer instance
14:28:46 <enikanorov> we had discussion with samuelbercovici
14:28:59 <enikanorov> I also got some opinions from tempest folks
14:29:08 <enikanorov> whos tests i was going to break with this :)
14:29:41 <enikanorov> so the common opinion is to preserve API compatibility, so scenarios for the previos API would work
14:30:12 <enikanorov> i think it's achievable by allowing user/client to start creating configuration from the pool
14:30:15 <enikanorov> as it is right now
14:30:32 <enikanorov> so the instance will be created for the pool automatically
14:31:04 <enikanorov> that's the general plan
14:31:47 <Vijay_> ok, for each pool that is created without the loadbalancerinstance id, a loadbalance instance will be created?
14:31:56 <enikanorov> Vijay_: correct
14:32:03 <s3wong> enikanorov: so in this case, the haproxy instance will be launched when a pool is created?
14:32:19 <obondarev> but multiple vips per pool will change things, right?
14:32:20 <enikanorov> s3wong: no, for haproxy it will also remain as it is today
14:32:32 <enikanorov> haproxy is pawned when vip is attached to the pool
14:32:59 <enikanorov> obondarev: multiple vips/pools could be just attached to existing instance
14:33:25 <enikanorov> if vip is concerned then you either attach it to the pool or to the instance
14:33:42 <enikanorov> if you attach it to the pool, instance id is deduced from the pool
14:34:17 <obondarev> ok, got it
14:34:29 <Vijay_> if poolid is globally unique and if it is not per loadbalancer then it should be fine.
14:35:04 <enikanorov> Vijay_: right
14:35:20 <enikanorov> samuelbercovici: do you have questions on loadbalancer instance?
14:35:52 <Vijay_> what is the plan for rest of the entities?
14:35:53 <iwamoto> I think API spec should be written and reviewed
14:36:14 <Vijay_> new entities like l7 policy and l7rule
14:36:18 <samuelbercovici> enikanorov: i would have prefered what we discussed together. anyway, when do u plan to modify your wiki, i will then give it further thought
14:36:19 <enikanorov> iwamoto: I have wiki page on this feature, i'll add API there
14:36:26 <Vijay_> should that also be tied to loadbalancer instance
14:36:56 <enikanorov> Vijay_: let's discuss it next
14:36:58 <enikanorov> samuelbercovici: ok
14:37:56 <avishayb> I have published a wiki page on l7 switching (WIP)
14:38:07 <avishayb> https://wiki.openstack.org/wiki/Neutron/LBaaS/l7
14:38:42 <enikanorov> I have general concern on L7 feature:
14:38:46 <avishayb> got some feedback from Vijay
14:39:17 <enikanorov> it's implementation depends on multiple pool per vipm which in turn depend on the instance
14:39:33 <enikanorov> so my question would be how are you planning to go with implementation?
14:40:10 <avishayb> I do not think it depends on the other tasks you mentioned.
14:40:49 <enikanorov> ok, but how do you plan to test it?
14:41:01 <enikanorov> if multiple pools are not there
14:41:04 <avishayb> I will add more details to the wiki page and than it may be clear why it is a standalone feature
14:41:12 <enikanorov> ok, good
14:41:26 <Vijay_> when will it be sent to the driver? Is it taking the monitoring approach?
14:41:31 <avishayb> can you please elaborate about "how do you plan to test it?"
14:42:07 <enikanorov> i mean it seems that in order to do end-to-end testing you need to get actual schema with m:n vip-pool relation ship
14:42:14 <enikanorov> which is a complex change
14:42:23 <avishayb> good point. I will address it on the wiki page
14:42:31 <enikanorov> ok
14:43:17 <avishayb> Vijay_ - same for you.. I will address it in the wiki :-)
14:44:17 <enikanorov> ok, any updates on SSL termination feature?
14:44:37 <Vijay_> we need to reach concensus on certificates
14:45:11 <evgenyf> My WIKI page (https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL) was updated with Vijey's points.
14:45:33 <evgenyf> Dilema about entities hierarchy is still open
14:46:09 <Vijay_> as i said in the mailing list, would prefer to have certificate created as a seprate resource with VIP  parameter
14:46:41 <enikanorov> Vijay_: how are you going to use it if it doesn't contain certificate itself?
14:47:11 <Vijay_> it will contain key, certificate and certificate chain along with the vip parameter
14:47:26 <enikanorov> so you're proposing to store certificate in the DB?
14:47:30 <Vijay_> no
14:47:58 <Vijay_> since the vip parameter is available we should be able to find the driver associated with it and send it to the correct driver
14:48:08 <Vijay_> so this is the flow
14:48:23 <Vijay_> create vip, create certificate (with vip).
14:48:58 <enikanorov> ok, certificate data is stored where?
14:49:03 <Vijay_> in the device
14:49:16 <Vijay_> the key will be transient
14:49:39 <enikanorov> how to reuse the certificate resource then?
14:49:50 <Vijay_> it wont be available for reuse
14:50:07 <enikanorov> what's the point of having it as separate resource then?
14:50:18 <samuelbercovici> in both aproache (embedding in the VIP or creating certificate associate with a VIP), the difference is the workflow the effect is the same
14:50:41 <Vijay_> Sam: right, the model is easier to migrate to future
14:51:02 <enikanorov> what are planned changes to this model?
14:51:13 <samuelbercovici> i prefere the "embedding" model as it is simple and when we get to have ke management with persistant capabilities, we can add the certificate as a 1st level citizen
14:51:47 <samuelbercovici> doing it now, might encour API changes which are not backward compatible
14:52:29 <samuelbercovici> so doing a "simple" model now, and adding a reusable model when we can store keys would be my prefered choice
14:52:48 <Vijay_> if there are VIPs with embeded certificate params, when there are certificate independent how will it be
14:53:04 <Vijay_> we might have a certificate parameter in the VIP?
14:53:09 <enikanorov> i still would like to know how the model with independent certificate will evolve
14:53:23 <enikanorov> e.g. what would be that 'future migration'
14:54:05 <enikanorov> because it is the only point imo that decides the better approach here
14:54:20 <Vijay_> ok. ill write the migration path in a do
14:54:22 <Vijay_> *doc
14:54:28 <Vijay_> and circulate
14:54:36 <enikanorov> ok
14:55:10 <Vijay_> also, backend certificates need to be accomodated
14:55:14 <samuelbercovici> i think, that having two models "basic" and in the future "resuable/persitant" mitigate the migration need. it is somewhat of a YAGNY
14:55:35 <samuelbercovici> YAGNI
14:56:05 <enikanorov> ok
14:56:29 <enikanorov> any other topics?
14:56:32 <samuelbercovici> Vijay_: backed, do not need cirtificates.
14:57:01 <Vijay_> how will the VIP authenticate the certificate presentd by backend if it is HTTPS service?
14:57:35 <s3wong> enikanorov: is the ability to set floating IP as VIP (i.e., service insertion) part of Icehouse plan?
14:57:39 <samuelbercovici> the VIP is "simulating" a client, I think that you refer to CA for the backend
14:57:58 <samuelbercovici> right?
14:58:16 <enikanorov> s3wong: not exactly. I saw embrane driver tried to do that
14:58:26 <Vijay_> yes the loadbalancer will act as a client and send make a seperate handshake with the backend service
14:58:32 <enikanorov> i mean that i would leave it up to vendors impelmentations
14:58:32 <s3wong> LVS driver has done some work there as well
14:59:10 <Vijay_> as part of the handshake the backend service is going to present a server certificate
15:00:41 <samuelbercovici> yes, and the allowed CA, might need to be set in the backend if you want to be strict
15:00:54 <enikanorov> i think our time is up
15:01:04 <enikanorov> we can continue on #neutron-lbaas or on ML
15:01:04 <samuelbercovici> Vijay_: lest discuss offline
15:01:07 <enikanorov> #endmeeting