16:00:54 #startmeeting neutron lbaas 16:00:55 Meeting started Tue Nov 18 16:00:54 2014 UTC and is due to finish in 60 minutes. The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:58 The meeting name has been set to 'neutron_lbaas' 16:01:06 #topic Roll call and Agenda 16:01:11 o/ 16:01:12 o/ 16:01:12 #link https://wiki.openstack.org/wiki/Network/LBaaS#Meeting_18.11.2014 16:01:13 o/ 16:01:17 o/ 16:01:25 sbalukoff: yes, i was just spacing out in my chair. 16:01:31 o/ 16:01:33 o/ 16:01:36 hi 16:01:40 Howdy, folks! 16:01:41 * pc_m lurking 16:01:45 Once again, thanks for changing the meeting time. 16:02:04 o/ 16:02:11 it's 4pm here. i'll be grateful next week. :) 16:02:35 #topic Announcements 16:02:44 latest v2 review to focus on: 16:02:45 #link https://review.openstack.org/#/c/123485/ 16:02:45 sbalukoff I take it you didn't go to the neutron meeting :-) 16:02:46 o/ 16:03:12 anyone have anything else to announce? 16:03:14 xgerman: Nope! 16:03:40 #topic Advanced services split 16:03:55 i'm going to defer to the recent neutron meeting here: 16:03:59 #link http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.html 16:03:59 #link http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.log.html 16:04:02 o/ 16:04:09 the short answer was, not much of an update yet. 16:05:18 i want to say, IMO, we should *not* be stalling lbaas v2 or octavia while we wait on this split. 16:05:20 I think we have time for the long answer 16:05:39 dougwig: +1 16:05:51 dougwig +1 -- but I am not sure how our chances us to make progress to get it merged without the split 16:05:55 my understanding (and the direction I was leaning) was continuing full steam on octavia but slightly stalling neutron-lbaas work >_> 16:06:03 xgerman ++ 16:06:15 im here! 16:06:18 we still have our feature branch, so i don't see why we'd need to stall. 16:06:43 yeah, we need to get everything merged into the feature branch. 16:07:06 well, I'd much rather get 100% returns on Octavia work in the meantime, get that up and working, then focus on neutron-lbaas when we're in a better position to get things done quickly and effectively (when we know what's going on) 16:07:14 but 16:07:44 we do still need to keep an eye on it so we don't lose whatever momentum we gained with regard to making the split actually happen 16:07:50 i don't think we need a lot of focus on lbaas; just enough to deal with -1's. 16:07:58 getting the reviews merged into the feature branch that have not will help 16:08:10 blogan +1 16:08:23 and it won't take much time from our standpoint to push for that and to pester to people 16:08:30 and I will see if I can get some of our QA look at v2 16:09:01 we also want to try it in a bigger installation than devstack 16:09:02 is ctracey around? is he going to update the client/cli, or should we find someone else to pick that up? 16:09:36 well, the TLS stuff in neutron-lbaas is very much broken/old/WIP 16:09:41 well that depends on how the client will get split as well 16:09:52 dougwig: I'm guessing we should find someone else to pick that up. 16:09:56 so I'll need to look at that again 16:10:00 rm_work: good point 16:10:23 He's been very distracted by other BBG priorities, and I don't realistically expect him to spend time on LBaaS in the near future. 16:10:36 sbalukoff: ok 16:10:54 #action dougwig coordinate someone to take over client/cli lbaas stuff, maybe 16:10:56 i nominate sbalukoff 16:11:11 (who can't program) 16:11:21 rm_work: did evgenyf update the tis stuff? or are you? or someone else? 16:11:22 rm_work: Do you mean the Barbican Util? 16:11:23 lol he can program in perl 16:11:24 he said he CAN, just slowly and badly :P 16:11:48 evgenyf: yes, because for one, it is no longer a Barbican Util 16:11:49 :) 16:11:51 rm_work: +1 16:12:24 that whole thing is going to be replaced with CertManager (the interface that merged to Octavia for talking to SecretStore backends) 16:12:24 so we're saying that many of the reveiws that are currently ready for review in the feature branch are no longer valid? 16:12:29 as in they should be WIPs? 16:12:34 possibly 16:12:46 can we mark them accordingly? 16:12:47 for the TLS ref impl the certmanager stuff is only real blocker 16:13:02 if were still using that 16:13:08 yeah dougwig took over ownership of all of them so only he can WIP :/ 16:13:15 do we have a volunteer to fold that into the current review for the feature branch? 16:13:17 * blogan shakes fist at dougwig 16:13:24 rm_work: which do you want WIP'ed? 16:13:49 https://review.openstack.org/#/c/123492/ needs it 16:13:50 #action rm_work msg dougwig for WIP reviews 16:14:15 /msg dougwig https://review.openstack.org/#/c/123492/ 16:14:24 #done 16:14:36 we need to fold the cert manager stuff into that one, right? 16:14:39 yes 16:14:48 any takers for that? 16:14:51 A large amount of that code is going to be straight up replaced 16:14:55 that would also kind of make the needed by review a WIP as well 16:14:57 I had assumed I would do it 16:15:06 dougwig: I will WIP TLS too 16:15:12 evgenyf: thanks 16:15:13 i had hoped; wasn't sure if you had cycles. 16:15:23 well, it all depends on priority :) 16:15:30 if we say this is a priority, I can get on it ASAP 16:15:57 i'm going to wager that octavia 0.5 is higher priority, due to the uncertainty. but if you get some cycles. 16:16:07 anyone else have an opinion on that? 16:16:55 i think making it a priority bc i dont want the split happening if these reviews do not get merged in 16:17:07 blogan +1 16:17:08 i mean i dont watn the split dependent on these reviews 16:17:15 I agree 16:17:24 Can you please point me to the Octavia CertManager code? 16:17:34 of course the bigger bottleneck will be getting core review time, per usual 16:17:47 evgenyf: https://review.openstack.org/#/c/131889/ 16:17:57 evgenyf: ignore anything about CertGenerator 16:18:02 we only need CertManager 16:18:04 rm_work: have you talked to the oslo folks at all about a common cert client library? 16:18:22 (maybe that could be you!) 16:18:22 dougwig: yes, it's going to be a new project, probably named "Castellan" 16:18:27 evgenyf: https://review.openstack.org/#/c/131889/9/octavia/certificates/manager/cert_mgr.py 16:18:29 rm_work: thanks 16:18:34 very simple interface 16:18:38 Huh. 16:19:05 dougwig / sbalukoff: Castellan (manager of a castle) :P 16:19:18 starting from Cinder's KeyMgr interface, rolling Cert support into it 16:19:33 is "the plan" right now 16:19:34 Castellan :-) 16:19:39 nice. 16:19:56 rm_work: please update that review when you get some time. i'd like to see things tied in a bow, like blogan, but i don't know what rax wants to see done first. let us know if it's going to get starved for time. 16:19:59 and when I say "the plan" I mean "my plan" because that is not yet "their plan" but i'm working on it :) 16:20:23 yeah, I think I'm going to bump my current sprint topic a bit and work on that, it shouldn't take me too long 16:20:30 dougwig: since rax will be using the v2 api and octavia, they're all kind of the same level of priority 16:20:37 at least that's what my advice would be 16:21:06 blogan is always right. except for the many times that he is not. but he's right this time. 16:21:20 * blogan chokes dougwig 16:21:31 on that note... 16:21:33 #topic Drivers, splitting status into operational and provisioning, and getting rid of DEFERRED 16:21:44 we talked about this at the summit. was anyone against it? 16:22:04 I never really got the rundown... 16:22:14 didn't we decide to work with the ML2 folks and use task flow? 16:22:17 but I was sort of out of the loop of those internals, so don't mind me I guess 16:22:18 DEFERRED is the devil 16:22:31 xgerman this is a separate topic really 16:22:45 I like to mix topics 16:22:53 you like mix ins eh? 16:22:59 I like to mix drinks, but 10am isn't the time for it :P 16:23:06 we are overloading the status field for operational and provisioning status, which results in ambiguity when something is provisioned but not yet useful. thus, the DEFERRED state was born, and it is complex, and that complexity is owned by the drivers. splitting that field makes the complexity disappear. 16:23:35 dougwig: sounds good to me, as long as that description isn't leaving anything out :) 16:23:41 well using taskflow would make the complexity owned by the plugin and not the drivers, but it still needs to go 16:23:45 xgerman: yes, this is subtly inter-related to the other meeting topics. 16:23:57 :-) 16:23:59 ok, let's go there 16:24:00 #topic Drivers, potential taskflow model, all async 16:24:04 blogan, want to summarize this one? 16:24:48 dougwig: do we have some proposal paper for splitting status? 16:24:53 well we would like to get all the db logic out of the drivers, and go to the exception model where the drivers throw an exception if something went wrong and the plugin catches tehse and updates the statuses accordingly 16:25:20 looks like using taskflow will be the best way to do this, it will make the lbaas API async no matter what driver is being used 16:25:54 taskflow is still a wip? 16:25:55 the problem is that neutron will be using taskflow as well and possibly in a different manner such that if we start using it now we may have to change how the drivers work as well when neutron's usage of taskflow happens 16:25:59 https://github.com/openstack/taskflow 16:26:53 a2hill: yes, that's really the only issue with using that model for drivers. we can't just wait for it and neutron's use of it to be "done", so we need something in the interim. 16:27:16 hence, getting rid of deferred and then basically sticking with a driver model similar to v1 in the interim. 16:27:23 Agreed, just wanted that fact stated. ;) 16:27:27 dougwig: do you expect neutron to change how taskflow works or we will have to import a neutron.taskflow library to use it? 16:28:00 I thought the ML2 plugin will use it 16:28:06 it will/is 16:28:06 and we can use their model 16:28:16 so we can just be like them? 16:28:22 yeah we need to talk to them some more 16:28:28 i would expect we'd import or derive from some neutron base class, but it's really up in the air right now. 16:28:47 well, deriving from ML2 might be ok 16:28:51 to xgerman's point, if its good enough for ML2 to use right now, why wouldn't it be good enough for us to use? 16:28:58 blogan +1 16:29:22 blogan +1 16:29:26 it probably is; i don't much like re-implementing the glue twice in parallel, though. 16:29:41 dougwig +1 16:29:51 i think more conversations with ML2 is warranted 16:29:58 +1 16:30:05 and also markmcclain, just to gauge the stability of it 16:30:11 or volatility 16:30:17 this topic was meant as an intro for everyone, today. 16:30:49 ok, while we're beating drivers to death... 16:30:50 #topic v2 Object Model - Potentially simplifying the object relations or making the objects purely logical constructs 16:30:55 well, once you switch to exceptions the driver can throw operational and provisioning things and we can slot them into the right place 16:31:47 during the summit, we asked if we should further simplify the object model to not have as many root objects, which led to sam restating his desire to see the models with many-to-many, and have us basically pass full trees around. 16:32:30 evgenyf: do you think you could ask sam to send an email out with his proposal? 16:32:40 IMO - in the interests of not rehashing decisions we've made, i'm fine sticking with the delicate balance that we ended up with for v2. 16:32:47 or if you know it well enough to send it yourself? 16:32:50 blogan: I will ask him 16:32:50 other opinions/comments? 16:32:53 evgenyf: ty 16:32:56 dougwig +1 16:33:08 dougwig: I'm all for not re-hashing decisions if there's not a compelling reason to. 16:33:25 the compelling reason to me is that it is confusing 16:33:30 also we should wait until we have v2 ne in some trunk before we rock the boat 16:33:31 to an end-user 16:33:50 xgerman: +1 16:33:58 also solving this could potentially solve the DEFERRED status issue as well 16:34:15 but yeah none of these chanegs would go in until after the split happens 16:34:33 at least that is my interpretation of all of this 16:34:53 vivek's ui concept could make any of these schemes palatable. 16:35:52 unless i hear an objection, we'll wait for sam's email, and otherwise continue with the status quo. 16:35:58 Ultimately, I think it's a good idea to not have so many root objects. But again, does pushing for that now get us anything? 16:36:13 sbalukoff: not right now, but after the split 16:36:25 Right. 16:36:37 agreed 16:36:42 #topic Open discussion 16:36:47 discuss away... 16:36:49 it gets us something after the split in that we aren't drastically changing the v2 api from one release to the next 16:37:46 dougwig: manish was the guy who was giving us a run down of taskflow and ML2 right? 16:38:04 yes. 16:38:24 #action blogan discuss taskflow drivers with ML2 16:38:44 please include me -- I like taskflow :-) 16:38:56 Im still a bit unclear, but are we going to get the .5 driver in as a ref impl 'before' the split so it gets merged in? Or do we want to go forward with the ref impl that is there (wip atm)? 16:39:27 I think we will wait for the split and then decide what makes the most sense at that point 16:39:34 no, we are not going to tie the octavia and neutron schedules together. ref impl as is. 16:39:42 Fair enough 16:39:46 Thank you 16:39:47 yeah we shouldn't add any additional reviews to teh feature branch 16:39:52 goal 1: split. goal 2: take over the world. 16:39:57 +1 16:39:59 goal 3: profit? 16:40:05 :) 16:40:29 any other items to discuss? 16:40:58 adv services meeting next? 16:41:02 yes 16:41:04 a2hill: Yep 16:41:07 alright folks, thanks, and bye. 16:41:10 kk ;) 16:41:20 See y'all in 19 minutes! 16:41:24 #endmeeting