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