16:00:04 <dougwig> #startmeeting neutron lbaas
16:00:05 <openstack> Meeting started Tue Jan 20 16:00:04 2015 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:09 <openstack> The meeting name has been set to 'neutron_lbaas'
16:00:13 <dougwig> #topic good morning/evening
16:00:16 <dougwig> o/
16:00:18 <ajmiller> o/ hi
16:00:24 <xgerman> o/
16:00:30 <johnsom> o/
16:00:44 <jamiem> o/
16:00:52 <dougwig> agenda:
16:00:54 <dougwig> #link https://wiki.openstack.org/wiki/Network/LBaaS
16:02:17 <dougwig> #topic Announcements
16:02:24 <sballe__> o/
16:02:28 <dougwig> the usual mid-cycle reminder, kilo-2 reminder (2/5).
16:02:36 <dougwig> Next lbaasv2 review to focus on:
16:02:43 <dougwig> #link https://review.openstack.org/#/c/144831/5
16:02:52 <dougwig> any other announcements?
16:03:15 <blogan> lets try and get that one and the one after merged, just to reduce the insanity of the dependency chains
16:03:28 <sballe__> +1
16:03:38 <dougwig> got a link handy?
16:03:42 <dougwig> for the second.
16:03:54 <rm_work> ah, this is where people are
16:03:55 <rm_work> o/
16:03:58 <jorgem> o/
16:04:04 <jorgem> sorry thought it was in alt
16:04:09 <blogan> #link https://review.openstack.org/#/c/144832/
16:04:46 <dougwig> #topic Mid-cycle meetup details
16:04:51 <dougwig> #link https://etherpad.openstack.org/p/lbaas-kilo-meetup
16:05:09 <SantoshNetScaler> ##
16:05:22 <dougwig> I wanted to tear through the main areas quickly this morning.  Highlight areas that need an owner, and ask current owners if there's anything blocking them or that they need before the sprint.
16:05:32 <dougwig> 1. Finish outstanding v2 reviews (dougwig, blogan)
16:05:43 <dougwig> blogan, anything blocking us?
16:06:03 <blogan> not the first 2, but the one after will need a neutron review to be merged first
16:06:16 <dougwig> ok
16:06:20 <blogan> which im sure you will be able to help on come thursday ;)
16:06:22 <dougwig> 2. Complete Agent Ref Impl
16:06:38 <dougwig> i've seen the ref driver reviews have some activity. anyone signed up to agent-ify yet?
16:07:05 * dougwig hears crickets while waiting for his tea to brew.
16:07:20 <dougwig> 3. API Improvements (blogan)
16:07:28 <dougwig> this is the one with a neutron review, right?
16:07:31 <blogan> yep
16:07:36 <dougwig> 4. Client/CLI (johnsom)
16:07:42 <dougwig> johnsom in the house?
16:07:54 <johnsom> I got in touch with Ryan, he hasn't had time to work on the client
16:08:15 <dougwig> anything you need from the team in the next 2 weeks? any progress on neutron client vs openstack client?
16:08:25 <johnsom> I looked at the openstack client docs but I haven't yet looked at how much it aligns to the API
16:08:28 <blogan> you find out more on whether we should go with openstack-client or neutron client?
16:08:34 <blogan> oh ditto
16:08:42 <johnsom> I think we should get a neutron client out and working as we can get the reviews
16:09:04 <blogan> do you have the review that ctracey already had up?
16:09:35 <johnsom> So that is the path I think we should go down.  I know there is some work complete is that direction, but send me the link
16:09:55 <dougwig> #link https://review.openstack.org/#/c/111475/
16:10:06 <blogan> dougwig too quick
16:10:12 <xgerman> yeah, ajmiller knows all aboit it ;-)
16:10:15 <blogan> gerrit too damn slow
16:10:21 <johnsom> Yep.
16:10:22 <dougwig> i used the etherpad.  :)
16:10:30 <dougwig> #link https://etherpad.openstack.org/p/lbaas_reviews
16:10:53 <blogan> i dont care what mestery says about you, you actually aren't that dumb
16:11:03 <dougwig> any other issues/questions/blockers with the client for this morning?
16:11:11 <dougwig> haha.
16:11:17 <johnsom> I don't have any
16:11:23 <dougwig> 5. Tests - Rama (HP QA )
16:11:30 <dougwig> is Rama around? (what's his irc nick?)
16:11:55 <xgerman> he volunteered at one of our meetings so I pinned him down
16:12:01 <xgerman> he is still getting up to speed
16:12:03 <dougwig> xgerman: excellent.
16:12:12 <dougwig> is he able to attend the sprint, or will he be remote?
16:12:14 <blogan> are those tempest tests going into tree?
16:12:20 <xgerman> remote
16:12:21 <blogan> etherpad says he'll be remote
16:12:59 <dougwig> ok.  xgerman, can you check with him as to progress/blockers/anything he needs?
16:13:09 <xgerman> will do!
16:13:12 <dougwig> ty
16:13:17 <dougwig> 6. TLS (ptoohill, evgeny)
16:13:38 <dougwig> ptoohill or evgenyf awake yet?  :)
16:13:44 <ptoohill> Im working on updating the ref sync impl as of now
16:14:07 <ptoohill> evgenyf had a couple pieces to put together now that we have deps set up for the cert stuffs
16:14:12 <rm_work> Carlos and I have related reviews too, and all of the TLS related reviews are stuck at the end of that review chain we mentioned earlier
16:14:16 <ptoohill> and fixing tests all around
16:14:18 <evgenyf> I'm working on using real tls certificates manager code
16:14:33 <dougwig> great. anything blocking you guys besides reviews?
16:14:42 <ptoohill> No sir
16:14:45 <evgenyf> No
16:14:54 <dougwig> great.
16:14:56 <dougwig> 7. L7 (evgeny)
16:15:13 <dougwig> i saw these reviews got re-posted. are we waiting on anything else for them?
16:15:52 <dougwig> evgenyf: you're listed as tentative for the sprint. are you able to make it?
16:15:53 <evgenyf> re-proposed to neutron-lbaas, ready for review https://review.openstack.org/#/c/148232/
16:16:05 <evgenyf> dougwig, yes, extensions code is missing
16:16:50 <dougwig> can you propose the extension code against neutron, or do you need someone else to do that?
16:16:56 <blogan> he alreayd did it
16:17:07 <dougwig> oh, ok.
16:17:19 <ptoohill> awesomesauce
16:17:23 <dougwig> so that's all in review land.
16:17:31 <blogan> with unicorns
16:17:34 <dougwig> 8. Docs
16:17:41 <dougwig> did we resurrect the v2 api docs?
16:17:46 <blogan> thats what i was wondering
16:18:00 <blogan> email on ML saying they were looking at them and i didnt know they were viewable by anyone
16:18:12 <dougwig> who was the original author?
16:18:18 <xgerman> min
16:18:19 <blogan> min i believe
16:18:29 <xgerman> we have them in a Google drive
16:18:32 <dougwig> is she going to take that back over, or do we need a new owner?
16:18:41 <xgerman> I think she can do it
16:18:51 <dougwig> great. can you close the loop with her?
16:18:57 <xgerman> yep, will do
16:19:04 <dougwig> ty
16:19:06 <dougwig> (almost done)
16:19:09 <dougwig> 9. Heat?
16:19:14 <dougwig> do we need to do anything for heat?
16:19:29 <xgerman> well, we likely need to test that it works
16:19:47 <xgerman> but I never used heat
16:19:53 <blogan> won't heat need some code updates to support v2?
16:19:53 <dougwig> anyone want to wade into that for kilo?
16:20:00 <sballe__> What do we need to test with Heat?
16:20:16 <dougwig> sballe__: that's step 1 of the task.  :)
16:20:18 <sballe__> That we can orchestrate things with heat?
16:20:25 <jorgem> the spurs handled the heat just fine last year dougwig
16:20:40 <ptoohill> Out of left field
16:20:41 <sballe__> jorgem: :-)
16:20:42 <rm_work> johnsom: <_<
16:20:43 <jorgem> lol
16:20:49 <rm_work> err
16:20:52 <rm_work> jorgem: <_<
16:20:57 <jorgem> You can check that one off the list :)
16:20:57 <dougwig> sports humor in a nerd chatroom.  the whooshing noise is really loud.
16:21:02 <evgenyf> blogan: regarding extensions code proposal to neutron, I did not do it. Did you mean ptoohill did it?
16:21:16 <ptoohill> did i?
16:21:23 <dougwig> blogan: the l7 extension is proposed? i missed it, if so.
16:21:31 <evgenyf> ptoohill: did you ?:)
16:21:32 <blogan> evgenyf: maybe ptoohill did, i just saw it linked in your review
16:21:35 <sballe__> I have to look into heat fro some other project so if we can agree what we want to do woth heat I can probably sign up for it
16:21:39 <ptoohill> i havnt touched anything for l7
16:21:47 <blogan> nvm
16:21:59 <ptoohill> blogan, we were going to wait for that when i was messing with it
16:22:02 <blogan> i misread it
16:22:07 <blogan> misread the comment
16:22:08 <dougwig> evgenyf: can you re-propose the extension in neutron master?
16:22:12 <ptoohill> So, yea, that still needs to be done in that case
16:22:41 <evgenyf> dougwig: I will
16:22:47 <dougwig> back to heat, we'll leave that as open and needing an owner for now.
16:22:56 <dougwig> #action evgenyf Propose L7 extension in neutron master
16:23:08 <rm_work> dougwig: i think sballe__ possibly volunteered :P
16:23:09 <dougwig> 10. Horizon?
16:23:29 <dougwig> re: heat - Oh, missed that.  Sweet, thank you sable.
16:23:31 <dougwig> sballe.
16:23:54 <rm_work> who was it that was working on horizon before? one of the paypal guys?
16:24:01 <blogan> vivek
16:24:08 <dougwig> horizon - anyone heard from vivek lately? I think we're far enough into Kilo that we'd need to do it as an add-on module for horizon in our own repo.
16:24:57 <jorgem> have not heard from him lately
16:25:10 <dougwig> ok, i'll email him. i may have someone here that can work on that, if he doesn't have any cycles.
16:25:38 <blogan> here as in your office or in the channel?
16:25:47 <dougwig> and that's the list of big areas.  anything missing or any other meetup details anyone wants to talk about?
16:25:51 <dougwig> (as in my office.)
16:26:38 <dougwig> ok, moving on...
16:26:45 <dougwig> #topic Statuses (Provisioning and Operating) (blogan)
16:27:04 <SantoshNetScaler> Following is change-set addressing the earlier review comments for  NetScaler Driver for neutron_lbaas v2 APIs. https://review.openstack.org/#/c/148541/
16:27:51 <dougwig> blogan: this topic is all yours.
16:27:56 <dougwig> SantoshNetScaler: ty
16:28:07 <blogan> so dougwig last week you had mentioned that you thought the load balancer and listener objects would have operating status and everything else provisioning status
16:28:53 <blogan> currently all objects just have a status field, which means different things for each object
16:29:03 <dougwig> actually, i'd like *everything* to have both, and leave it up to the driver, but that's me.
16:29:47 <blogan> well that means the drivers have to do a lot of status management for every entity
16:29:49 <dougwig> (oh, you're going to leap on leaving it to the driver.  poor phrasing.  still with the automated provisioning statuses we've talked about previously.)
16:29:59 <blogan> lol
16:30:23 <blogan> what do you mean automated provisioning statuses?
16:31:19 <dougwig> in the normal cases, the plugin would manage status.  in exceptional cases, the driver could just raise.  some other mechanism to enable async and tell the plugin to leave it alone.  but the driver always handles operational.
16:32:43 <dougwig> this has the makings of a dougwig/blogan argument. shall we take it offline and into channel later, or do we have any other opinions?
16:32:54 <blogan> well that would require some extra work to get that automated provisioning status still, and id like for the operational status to somehow be managed by the plugin as well but realize that is not realistic in a short amount of time
16:32:58 <xgerman> I am with dougwig
16:33:56 <dougwig> blogan: we'd need some way for the underlying subsystem to communicated operational state back to the plugin, for the plugin to update the status.  like, maybe, updating the status?  :-)
16:34:21 <xgerman> also how does that all work wgen we say share pools
16:34:39 <blogan> i know, or other ways ive thought about but in the end it is the plugin reacting on something the driver did
16:35:05 <dougwig> xgerman: that goes back to the good argument to only have status trees in the LoadBalancer object.
16:35:06 * blogan jedi mind tricks xgerman
16:36:09 <xgerman> but that is a different discussion than having two fields
16:36:14 <xgerman> ;-)
16:36:19 <dougwig> i think one of us needs to write up a short proposal and try to converge on a plan.  we've had this discussion about 5 times now in a vacuum.  :)
16:36:41 <sballe__> dougwig: +1
16:36:44 <blogan> well if we have two fields on a pool, then we enable sharing then we'll have to remove those fields and cause a break in contract, which would cause a new version of the api
16:37:02 <dougwig> blogan: +1
16:37:20 <dougwig> nothing says we can't have two statuses, but only in the LB (or just one set in the LB)
16:37:37 <blogan> well one thing needs to be decided on, do we want to leave this version open to sharing objects?
16:37:59 <dougwig> i'm against sharing, and always have been.  :)
16:38:38 <blogan> well im against it right now as it is a big blocker and has been for a while
16:39:00 <xgerman> ok, no sharing works for me
16:39:02 <dougwig> seems to be a solution searching for a problem, to me.
16:39:16 <dougwig> i can see merit, but not enough to offset the implementation woes.
16:39:19 <blogan> well the problem is especially with L7 rules
16:39:27 <dougwig> autocorrect just made that "implementation whores"
16:39:31 <blogan> lol
16:39:48 <dougwig> i'd rather see M:N on an l7 parent object than of pools.
16:40:50 <blogan> anyone stongly in favor of sharing objects? (if only sam was here)
16:41:12 <jorgem> I need to understand the problem better
16:41:15 <ptoohill> speak of the devil
16:41:19 <ptoohill> jk
16:41:22 <jorgem> Is this on the ML somewhere?
16:41:25 <dougwig> short write-up to ML?  short, because no one reads long.
16:41:31 <blogan> its been a discussion for a long time
16:41:37 <rm_work> have we been using the ML for the past several months? >_>
16:41:38 <blogan> ill write it up
16:41:49 <rm_work> if so, i have some catching up to do
16:41:49 <jorgem> blogan: It was a discussion a long time ago you mean?
16:41:51 <blogan> im not sure i can keep it short though, but i will try
16:42:01 <blogan> no its been ongoing, peaks and valleys
16:42:32 <blogan> it always comes up bc it is a big decision that affects the api in a major way
16:42:35 <rm_work> ah i see posts about it from sam as recent as a month ago
16:42:42 <dougwig> #action blogan Two status/status tree/sharing of objects writeup to ML
16:43:10 <jorgem> blogan: Has the dust settled a bit on it at least. (i.e do we have a couple of options to compare?)
16:43:17 <dougwig> we just need to close on a plan and not be blocked, even if we can't get perfect consensus.
16:43:18 <blogan> yes 2 options
16:43:22 <jorgem> k
16:43:41 <blogan> one sam has proposed and the other option is no sharing and provisioning and operating statuses remain on the entities
16:44:03 <jorgem> okay ML it is
16:44:49 <blogan> so aside from that, we can still decide on which entities have provisioning and operating statuses
16:45:13 <xgerman> yeah, having two statuses shouldn't impact where they live
16:45:21 <dougwig> i'd suggest you pick one and just say that, instead of asking the ML to decide. if you pick the wrong one, everyone will scream.
16:45:34 <xgerman> + 1
16:45:40 <blogan> pick one of the sharing models or where the entities live?
16:45:46 <dougwig> yes.
16:45:49 <blogan> lol
16:45:54 <ptoohill> :P
16:46:02 <xgerman> we can have two sttauses and put them on an lb tree
16:46:08 <blogan> well im going to just go with what is there, which is similar to octavia
16:46:30 <dougwig> is that two status no sharing?
16:46:35 <blogan> xgerman: no point if we have two statuses on the entities and then introduce a tree, the statuses on the entities won't make sense if they're being shared
16:47:17 <blogan> unless you mean just a status tree on the lb without sharing
16:47:46 <xgerman> yep, there are just a ton of permutations
16:47:50 <blogan> two status is independent of sharing, its just where the statuses live that is dependent
16:47:56 <xgerman> yep
16:48:06 <dougwig> we could also put a status tree on the lb without sharing, and status helper methods in the sub-objects that go look in the parent.
16:48:31 <xgerman> exactly - and that might make it easier to got to sharing if we ever need to
16:48:43 <dougwig> 2 minutes, then we need to move on to other topics.
16:48:51 <blogan> and in the db it can remain on the entities, the api just doesn't show it in the entities
16:49:54 <blogan> thats going to look messy but i can go for that
16:50:20 <dougwig> ok, gotta move us along now.  blogan will take this up on the ML.
16:50:21 <xgerman> well, ML
16:50:25 <dougwig> #topic Add constraint that V1 and V2 cannot be enabled at the same time
16:50:31 <dougwig> another one for blogan!
16:51:08 <blogan> this came up with the client ctracey was writing and I believe we all agreed that we can put that constraint in, just wanted to bring it up if anyone disagrees with it
16:51:21 <jorgem> Hmm...
16:51:30 <jorgem> so this hits on the topic of versioning going forward
16:51:33 <jorgem> what are the plans there?
16:51:48 <ptoohill> What would you need v1 for if v2 is enabled?
16:51:51 <dougwig> i hate it as unnecessary. it came up because some folks wanted to overload the CLI/api endpoints between v1/v2.  i think i got out-voted.
16:51:51 <jorgem> For example, are we going to be able to host multiple versions, deprecate, etc.?
16:52:29 <xgerman> at one point we have to...
16:52:29 <rm_work> can we do versioning in our URL now?
16:52:34 <blogan> jorgem that will go into the neutron microversioning discussion, which is in its infancy but will probably follow the nova model which i dont fully understand
16:52:53 <dougwig> ptoohill: operationally, I'm not sure you would. it's handy from a dev perspective.  might also make lazy upgrades a possibility, though i'm not sure we have to worry about upgrades.
16:52:54 <rm_work> if we can version in our URL, it doesn't matter, the client can just take a VERSION setting (just like keystone, nova, etc)
16:53:05 <blogan> rm_work: no, still beholden to neutron's, unless we did neutron.com/v2.0/lbaas/v2.0
16:53:17 <rm_work> blogan: hmm, i don't mind that TOO much
16:53:24 <rm_work> it's not ideal...
16:53:27 <xgerman> microversions don't need the URL - they do so with the ACCEPT header
16:53:35 <rm_work> ok, so, that
16:53:39 <rm_work> header versioning
16:53:43 <blogan> ah
16:53:55 <rm_work> win?
16:54:08 <blogan> id still like to know how they version all their models and api entities
16:54:11 <blogan> in code
16:54:20 <rm_work> ugh
16:54:30 <rm_work> table-name prepend?
16:54:32 <rm_work> v1_
16:54:34 <rm_work> v2_ ?
16:54:35 <rm_work> lol
16:54:40 * blogan barfs of rm_work
16:54:45 <blogan> *on
16:54:55 <xgerman> nova also has sub_modules ewith their own verisons
16:55:04 <xgerman> but again I don't know how that works
16:55:12 <rm_work> yeah that's how web-shit always did it in the past (back when everyone coding for the web hated their lives -- oh wait that hasn't changed much)
16:55:13 <blogan> well lets tackle what we need to right now
16:55:28 <dougwig> i think we're too far along to stop and micro-version v2. unless someone disagrees with that, can we pull back to v1/v2 simultaneous or not?
16:55:46 <xgerman> we should go v2 only
16:55:51 <ptoohill> +1
16:55:54 <blogan> dougwig: thats honestly going to be up to the neutron code
16:55:55 <sballe__> +1
16:56:12 <rm_work> i feel like every time this comes up we ask "does anyone actually run v1?" <_<
16:56:27 <blogan> im all for v1 and v2 being mutually exclusive
16:56:39 <ptoohill> ^^ It would be nice if we could get hold of those magical unicorns that do run it and talk with them
16:56:52 <dougwig> i just pinged kevin to ask if neutron will require it. i doubt that it would, as existing extensions would all break.
16:57:11 <dougwig> ptoohill: what questions would you like to ask?
16:57:30 <rm_work> "do you care about running v1 and v2 at the same time?"
16:57:36 <rm_work> for starters
16:57:38 <ptoohill> oh, you are magical unicorn???
16:57:40 <ptoohill> but yea, that
16:57:49 <dougwig> i know many unicorns.
16:57:58 <dougwig> none of them would care.
16:58:03 <ptoohill> Would like to hear their opinion on that,
16:58:08 <ptoohill> well that settles that i suppose
16:58:11 <ptoohill> :P
16:58:11 <rm_work> k, well, that's an easy answer then
16:58:24 <dougwig> or rather, i'm sure they'd be fine running it on separate hosts.
16:58:35 <rm_work> ^^ holy shit this
16:58:47 <rm_work> who would even want to run it all on the same host <_<
16:58:58 <rm_work> and then, it doesn't matter at all
16:59:36 <rm_work> lbaas.myhost.com + v2.lbaas.myhost.com
16:59:40 <rm_work> done
16:59:59 <jorgem> eek
17:00:07 <blogan> well its the api node that decides which version to run
17:00:13 <blogan> or which plugin to run
17:00:19 <dougwig> yeah, that's what i'm pondering.
17:00:31 <blogan> so usually you just have one consistent api, two hosts for the api
17:00:33 <rm_work> ugh and neutron has to be our API host?
17:00:34 <dougwig> db tables need stay separate.
17:00:47 <dougwig> rm_work: for kilo, yes.
17:00:50 <blogan> for neutron-lbaas, for now yes
17:01:10 <rm_work> so they'd need different neutron hosts of the same version, for two different lbaas versions >_< bah
17:01:36 <blogan> which is what we had
17:01:43 <dougwig> yeah, i'm not liking that much.  different agent nodes, fine.  but then we get back to needing separate CLI commands.
17:01:46 <blogan> well what we had when we allowed both versoin to be running
17:02:14 <blogan> i think we're in a consensus, other than dougwigs reservations
17:02:16 <dougwig> maybe if we use a similar CLI namespace, but require an environment variable if they want to access v1 while v2 is loaded?
17:02:32 <dougwig> i can take my questions offline.
17:02:34 <dougwig> oops, we're over.
17:02:37 <dougwig> thanks and by folks.
17:02:39 <ptoohill> Ill work on the agent-ified driver BTW dougwig, forgot to respond earlier.
17:02:46 <dougwig> ptoohill: awesome, thanks.
17:02:50 <dougwig> #endmeeting