16:00:54 <dougwig> #startmeeting neutron lbaas
16:00:55 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:58 <openstack> The meeting name has been set to 'neutron_lbaas'
16:01:06 <dougwig> #topic Roll call and Agenda
16:01:11 <johnsom_> o/
16:01:12 <ajmiller> o/
16:01:12 <dougwig> #link https://wiki.openstack.org/wiki/Network/LBaaS#Meeting_18.11.2014
16:01:13 <a2hill> o/
16:01:17 <sballe> o/
16:01:25 <dougwig> sbalukoff: yes, i was just spacing out in my chair.
16:01:31 <jorgem> o/
16:01:33 <xgerman> o/
16:01:36 <SumitNaiksatam> hi
16:01:40 <sbalukoff> Howdy, folks!
16:01:41 * pc_m lurking
16:01:45 <sbalukoff> Once again, thanks for changing the meeting time.
16:02:04 <TrevorV_> o/
16:02:11 <dougwig> it's 4pm here.  i'll be grateful next week.  :)
16:02:35 <dougwig> #topic Announcements
16:02:44 <dougwig> latest v2 review to focus on:
16:02:45 <dougwig> #link https://review.openstack.org/#/c/123485/
16:02:45 <xgerman> sbalukoff I take it you didn't go to the neutron meeting :-)
16:02:46 <jamiem> o/
16:03:12 <dougwig> anyone have anything else to announce?
16:03:14 <sbalukoff> xgerman: Nope!
16:03:40 <dougwig> #topic Advanced services split
16:03:55 <dougwig> i'm going to defer to the recent neutron meeting here:
16:03:59 <dougwig> #link http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.html
16:03:59 <dougwig> #link http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.log.html
16:04:02 <rm_work> o/
16:04:09 <dougwig> the short answer was, not much of an update yet.
16:05:18 <dougwig> i want to say, IMO, we should *not* be stalling lbaas v2 or octavia while we wait on this split.
16:05:20 <xgerman> I think we have time for the long answer
16:05:39 <sbalukoff> dougwig: +1
16:05:51 <xgerman> dougwig +1 -- but I am not sure how our chances us to make progress to get it merged without the split
16:05:55 <rm_work> my understanding (and the direction I was leaning) was continuing full steam on octavia but slightly stalling neutron-lbaas work >_>
16:06:03 <rm_work> xgerman ++
16:06:15 <blogan> im here!
16:06:18 <dougwig> we still have our feature branch, so i don't see why we'd need to stall.
16:06:43 <xgerman> yeah, we need to get everything merged into the feature branch.
16:07:06 <rm_work> 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 <rm_work> but
16:07:44 <rm_work> 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 <dougwig> i don't think we need a lot of focus on lbaas; just enough to deal with -1's.
16:07:58 <blogan> getting the reviews merged into the feature branch that have not will help
16:08:10 <xgerman> blogan +1
16:08:23 <blogan> and it won't take much time from our standpoint to push for that and to pester to people
16:08:30 <xgerman> and I will see if I can get some of our QA look at v2
16:09:01 <xgerman> we also want to try it in a bigger installation than devstack
16:09:02 <dougwig> is ctracey around?  is he going to update the client/cli, or should we find someone else to pick that up?
16:09:36 <rm_work> well, the TLS stuff in neutron-lbaas is very much broken/old/WIP
16:09:41 <blogan> well that depends on how the client will get split as well
16:09:52 <sbalukoff> dougwig: I'm guessing we should find someone else to pick that up.
16:09:56 <rm_work> so I'll need to look at that again
16:10:00 <blogan> rm_work: good point
16:10:23 <sbalukoff> 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 <dougwig> sbalukoff: ok
16:10:54 <dougwig> #action dougwig coordinate someone to take over client/cli lbaas stuff, maybe
16:10:56 <blogan> i nominate sbalukoff
16:11:11 <xgerman> (who can't program)
16:11:21 <dougwig> rm_work: did evgenyf update the tis stuff?  or are you?  or someone else?
16:11:22 <evgenyf> rm_work: Do you mean the Barbican Util?
16:11:23 <blogan> lol he can program in perl
16:11:24 <rm_work> he said he CAN, just slowly and badly :P
16:11:48 <rm_work> evgenyf: yes, because for one, it is no longer a Barbican Util
16:11:49 <sbalukoff> :)
16:11:51 <sbalukoff> rm_work: +1
16:12:24 <rm_work> that whole thing is going to be replaced with CertManager (the interface that merged to Octavia for talking to SecretStore backends)
16:12:24 <blogan> 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 <blogan> as in they should be WIPs?
16:12:34 <rm_work> possibly
16:12:46 <xgerman> can we mark them accordingly?
16:12:47 <a2hill> for the TLS ref impl the certmanager stuff is only real blocker
16:13:02 <a2hill> if were still using that
16:13:08 <rm_work> yeah dougwig took over ownership of all of them so only he can WIP :/
16:13:15 <dougwig> 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 <dougwig> rm_work: which do you want WIP'ed?
16:13:49 <rm_work> https://review.openstack.org/#/c/123492/ needs it
16:13:50 <dougwig> #action rm_work msg dougwig for WIP reviews
16:14:15 <rm_work> /msg dougwig https://review.openstack.org/#/c/123492/
16:14:24 <rm_work> #done
16:14:36 <dougwig> we need to fold the cert manager stuff into that one, right?
16:14:39 <rm_work> yes
16:14:48 <dougwig> any takers for that?
16:14:51 <rm_work> A large amount of that code is going to be straight up replaced
16:14:55 <blogan> that would also kind of make the needed by review a WIP as well
16:14:57 <rm_work> I had assumed I would do it
16:15:06 <evgenyf> dougwig: I will WIP TLS too
16:15:12 <blogan> evgenyf: thanks
16:15:13 <dougwig> i had hoped; wasn't sure if you had cycles.
16:15:23 <rm_work> well, it all depends on priority :)
16:15:30 <rm_work> if we say this is a priority, I can get on it ASAP
16:15:57 <dougwig> 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 <dougwig> anyone else have an opinion on that?
16:16:55 <blogan> i think making it a priority bc i dont want the split happening if these reviews do not get merged in
16:17:07 <xgerman> blogan +1
16:17:08 <blogan> i mean i dont watn the split dependent on these reviews
16:17:15 <sballe> I agree
16:17:24 <evgenyf> Can you please point me to the Octavia CertManager code?
16:17:34 <blogan> of course the bigger bottleneck will be getting core review time, per usual
16:17:47 <rm_work> evgenyf: https://review.openstack.org/#/c/131889/
16:17:57 <rm_work> evgenyf: ignore anything about CertGenerator
16:18:02 <rm_work> we only need CertManager
16:18:04 <dougwig> rm_work: have you talked to the oslo folks at all about a common cert client library?
16:18:22 <dougwig> (maybe that could be you!)
16:18:22 <rm_work> dougwig: yes, it's going to be a new project, probably named "Castellan"
16:18:27 <rm_work> evgenyf: https://review.openstack.org/#/c/131889/9/octavia/certificates/manager/cert_mgr.py
16:18:29 <evgenyf> rm_work: thanks
16:18:34 <rm_work> very simple interface
16:18:38 <sbalukoff> Huh.
16:19:05 <rm_work> dougwig / sbalukoff: Castellan (manager of a castle) :P
16:19:18 <rm_work> starting from Cinder's KeyMgr interface, rolling Cert support into it
16:19:33 <rm_work> is "the plan" right now
16:19:34 <xgerman> Castellan :-)
16:19:39 <dougwig> nice.
16:19:56 <dougwig> 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 <rm_work> 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 <rm_work> 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 <blogan> dougwig: since rax will be using the v2 api and octavia, they're all kind of the same level of priority
16:20:37 <blogan> at least that's what my advice would be
16:21:06 <dougwig> 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 <dougwig> on that note...
16:21:33 <dougwig> #topic Drivers, splitting status into operational and provisioning, and getting rid of DEFERRED
16:21:44 <dougwig> we talked about this at the summit.   was anyone against it?
16:22:04 <rm_work> I never really got the rundown...
16:22:14 <xgerman> didn't we decide to work with the ML2 folks and use task flow?
16:22:17 <rm_work> but I was sort of out of the loop of those internals, so don't mind me I guess
16:22:18 <blogan> DEFERRED is the devil
16:22:31 <blogan> xgerman this is a separate topic really
16:22:45 <xgerman> I like to mix topics
16:22:53 <blogan> you like mix ins eh?
16:22:59 <rm_work> I like to mix drinks, but 10am isn't the time for it :P
16:23:06 <dougwig> 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 <rm_work> dougwig: sounds good to me, as long as that description isn't leaving anything out :)
16:23:41 <blogan> well using taskflow would make the complexity owned by the plugin and not the drivers, but it still needs to go
16:23:45 <dougwig> xgerman: yes, this is subtly inter-related to the other meeting topics.
16:23:57 <xgerman> :-)
16:23:59 <dougwig> ok, let's go there
16:24:00 <dougwig> #topic Drivers, potential taskflow model, all async
16:24:04 <dougwig> blogan, want to summarize this one?
16:24:48 <evgenyf> dougwig: do we have some proposal paper for splitting status?
16:24:53 <blogan> 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 <blogan> 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 <a2hill> taskflow is still a wip?
16:25:55 <blogan> 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 <dougwig> https://github.com/openstack/taskflow
16:26:53 <dougwig> 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 <dougwig> hence, getting rid of deferred and then basically sticking with a driver model similar to v1 in the interim.
16:27:23 <a2hill> Agreed, just wanted that fact stated. ;)
16:27:27 <blogan> 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 <xgerman> I thought the ML2 plugin will use it
16:28:06 <blogan> it will/is
16:28:06 <xgerman> and we can use their model
16:28:16 <xgerman> so we can just be like them?
16:28:22 <blogan> yeah we need to talk to them some more
16:28:28 <dougwig> 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 <xgerman> well, deriving from ML2 might be ok
16:28:51 <blogan> 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 <xgerman> blogan +1
16:29:22 <johnsom_> blogan +1
16:29:26 <dougwig> it probably is; i don't much like re-implementing the glue twice in parallel, though.
16:29:41 <a2hill> dougwig +1
16:29:51 <blogan> i think more conversations with ML2 is warranted
16:29:58 <dougwig> +1
16:30:05 <blogan> and also markmcclain, just to gauge the stability of it
16:30:11 <blogan> or volatility
16:30:17 <dougwig> this topic was meant as an intro for everyone, today.
16:30:49 <dougwig> ok, while we're beating drivers to death...
16:30:50 <dougwig> #topic v2 Object Model - Potentially simplifying the object relations or making the objects purely logical constructs
16:30:55 <xgerman> 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 <dougwig> 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 <blogan> evgenyf: do you think you could ask sam to send an email out with his proposal?
16:32:40 <dougwig> 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 <blogan> or if you know it well enough to send it yourself?
16:32:50 <evgenyf> blogan: I will ask him
16:32:50 <dougwig> other opinions/comments?
16:32:53 <dougwig> evgenyf: ty
16:32:56 <xgerman> dougwig +1
16:33:08 <sbalukoff> dougwig: I'm all for not re-hashing decisions if there's not a compelling reason to.
16:33:25 <blogan> the compelling reason to me is that it is confusing
16:33:30 <xgerman> also we should wait until we have v2 ne in some trunk before we rock the boat
16:33:31 <blogan> to an end-user
16:33:50 <sbalukoff> xgerman: +1
16:33:58 <blogan> also solving this could potentially solve the DEFERRED status issue as well
16:34:15 <blogan> but yeah none of these chanegs would go in until after the split happens
16:34:33 <blogan> at least that is my interpretation of all of this
16:34:53 <dougwig> vivek's ui concept could make any of these schemes palatable.
16:35:52 <dougwig> unless i hear an objection, we'll wait for sam's email, and otherwise continue with the status quo.
16:35:58 <sbalukoff> 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 <blogan> sbalukoff: not right now, but after the split
16:36:25 <sbalukoff> Right.
16:36:37 <dougwig> agreed
16:36:42 <dougwig> #topic Open discussion
16:36:47 <dougwig> discuss away...
16:36:49 <blogan> 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 <blogan> dougwig: manish was the guy who was giving us a run down of taskflow and ML2 right?
16:38:04 <dougwig> yes.
16:38:24 <dougwig> #action blogan discuss taskflow drivers with ML2
16:38:44 <xgerman> please include me -- I like taskflow :-)
16:38:56 <a2hill> 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 <xgerman> I think we will wait for the split and then decide what makes the most sense at that point
16:39:34 <dougwig> no, we are not going to tie the octavia and neutron schedules together.  ref impl as is.
16:39:42 <a2hill> Fair enough
16:39:46 <a2hill> Thank you
16:39:47 <blogan> yeah we shouldn't add any additional reviews to teh feature branch
16:39:52 <dougwig> goal 1: split.  goal 2: take over the world.
16:39:57 <xgerman> +1
16:39:59 <blogan> goal 3: profit?
16:40:05 <a2hill> :)
16:40:29 <dougwig> any other items to discuss?
16:40:58 <a2hill> adv services meeting next?
16:41:02 <dougwig> yes
16:41:04 <sbalukoff> a2hill: Yep
16:41:07 <dougwig> alright folks, thanks, and bye.
16:41:10 <a2hill> kk ;)
16:41:20 <sbalukoff> See y'all in 19 minutes!
16:41:24 <dougwig> #endmeeting