16:00:10 <dougwig> #startmeeting neutron lbaas
16:00:11 <openstack> Meeting started Tue Nov 25 16:00:10 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:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:15 <openstack> The meeting name has been set to 'neutron_lbaas'
16:00:21 <dougwig> #topic Roll call and Agenda
16:00:21 <sbalukoff> Howdy, folks!
16:00:22 <dougwig> hiya
16:00:26 <ajmiller> o/
16:00:26 <dougwig> #link https://wiki.openstack.org/wiki/Network/LBaaS#Meeting_25.11.2014
16:00:31 <blogan> \o/
16:01:20 <dougwig> #topic Announcements
16:01:23 <xgerman_> \o/ - nobody vacations like blogan
16:01:28 <dougwig> lol
16:01:34 <blogan> i'm a masochist
16:01:40 <dougwig> our fourth v2 review merged!  thanks oleg and mestery!
16:01:47 <dougwig> next review that needs attention: #link https://review.openstack.org/#/c/123487/
16:01:50 <xgerman_> go see the sights -- the alamo is nice thgis time of year!
16:02:08 <dougwig> any other announcements, besides that blogan doesn't know how to vacation?
16:02:25 <sballe> o/
16:02:33 <dougwig> #topic Subteam charter
16:02:34 <blogan> that review needs to be fixed for jenkins and address some comments, ill try to do that today
16:02:53 <xgerman_> also we are looking to gte in touch with mlavalle -- we ant to run the tempest tests
16:02:54 <dougwig> mestery introduced this wiki yesterday: https://wiki.openstack.org/wiki/NeutronSubteamCharters
16:03:03 <dougwig> i put in a quick blurb for us, but if anyone disagrees, holler.
16:03:10 <dougwig> #link https://wiki.openstack.org/wiki/NeutronSubteamCharters
16:03:40 <blogan> i disagree with the rainbows
16:03:50 <xgerman_> I on the other hand like them
16:04:03 <xgerman_> but I also want unicorns, lots of them
16:04:04 <sbalukoff> The rainbows are important.
16:04:06 <dougwig> gerrit fight.  go!
16:04:10 <sbalukoff> xgerman +1
16:04:25 <blogan> i do have a question that is somewhat related
16:04:49 <dougwig> shoot
16:04:53 <rm_work> yo
16:05:06 <blogan> if we want all reviews merged into the feature branch, it is not in our best interest to add more reviews to be merged to that feature branch
16:05:15 <xgerman_> +1
16:05:25 <blogan> which means it is not in our best interest to add new features or change things until after the split
16:05:55 <dougwig> in my mind, we keep going with the feature branch as if the split isn't going to happen.  when the split occurs, a few reviews might need to be moved.
16:06:20 <blogan> so what if getting things merged into the feature branch becomes a blocker to getting the split done?
16:06:30 <blogan> mark has hinted this could be the case
16:06:53 <dougwig> the spec linked above calls out that case, and as not a blocker.
16:07:10 <dougwig> (doesn't mean that it's anywhere near consensus, but that topic hasn't come up yet.)
16:07:25 <blogan> consensus is like rainbows and unicorns
16:07:47 <dougwig> i don't like serializing stuff around imminent changes in openstack, since there are *always* imminent changes in openstack, and they can't all be relied upon.  we'd literally be in paralysis all the time.
16:07:59 <sballe> +1
16:08:02 <dougwig> that's just my opinion, though.
16:08:08 <sballe> mine too
16:08:15 <blogan> i know, i agree that there really shouldn't be a dependency on pending reviews into the feature branch
16:08:26 <xgerman_> I agree with getting v2 finished but I would elahy new work
16:08:38 <xgerman_> delay
16:08:46 <blogan> there's also the prospect of redoing some of the v2 api
16:08:53 <blogan> or changing some of it around
16:09:24 <xgerman_> I heard of that but we should continue our course
16:09:37 <dougwig> do we want to push for a feature branch in the split repo, to account for some kilo churn?
16:09:44 <vjay-netscaler> I didnt understand the conversation in full. what is the idea here, we get the split with code in main branch and then merge feature branch to split repo?
16:09:52 <blogan> yeah but id rather avoid kilo having one version of the v2 api only to change it for L
16:09:53 <dougwig> we also need to repropose our v2 specs for kilo
16:10:35 <sballe> blogan: What would the re-work on v2 be?
16:10:41 <xgerman_> sballe +1
16:10:56 <blogan> sballe: we've discussed in last meeting i think, removing the need for the DEFERRED status is one
16:11:00 <blogan> well its a big one
16:11:14 * TrevorV sorry I'm late :(
16:11:16 <blogan> then also having only one true root object, load balancer is a proposal
16:11:24 <sballe> blogan: ok I'll look at the meeting logs and will sync-up with you
16:11:26 <dougwig> blogan: we kind of got ourselves into that level of analysis paralysis when we first started getting consensus on v2.  it's not an api any of us love, but it did get consensus.  are we sure that if we go through that mill again that the result will be different/better?
16:11:41 <dougwig> DEFERRED was added on the fly late; i'm not sure removing it is all that noticeable.  the other stuff is bigger.
16:11:55 <xgerman_> yeah, I am very worried that we open a can of worms
16:11:56 <blogan> it was agreed on at the midcycle
16:12:16 <xgerman_> but that was before task flow
16:12:24 <blogan> well i guess the biggest change possibly is what Sam proposed on the ML
16:12:54 <xgerman_> yeah, and we are not in favor of it
16:13:24 <dougwig> let's put this stuff as alternatives (or the main proposal) in the specs for kilo and go for consensus in gerrit?
16:13:27 <sballe> I saw what Sam proposed but thought we were going to do that down the road if it still made sense. I do not feel we are down the road yet. We talked version 1.0 and we are not at v 0,5 of Octavaia yet
16:14:04 <blogan> dougwig +1
16:14:15 <dougwig> i'm just worried about being duke nukem forever, openstack edition.
16:14:15 <blogan> sballe: sam is talking about neutron lbaas v2 api
16:14:39 <sbalukoff> dougwig: +1
16:14:49 <sballe> blogan: I understand but I am still not in favor of touching that now
16:14:54 <dougwig> blogan: can you repurpose your v2 spec for kilo, and we'll continue there?
16:14:59 <dougwig> repropose
16:15:03 <blogan> sure
16:15:03 <sbalukoff> Neutron LBaaS v2 API does affect Octavia, though not initially.
16:15:06 <blogan> action me
16:15:15 <dougwig> #action blogan Re-propose lbaas v2 spec for Kilo
16:15:32 <blogan> repurpose works as well
16:15:35 <dougwig> ok, now that we're all warmed up...
16:15:36 <sbalukoff> Again, we need to get v0.5 first
16:15:37 <dougwig> #topic Advanced services split mechanics
16:15:46 <dougwig> #link https://review.openstack.org/#/c/136835/
16:16:06 <dougwig> any comments or discussion on that spec that we can do in slightly higher bandwidth irc meeting?
16:16:22 <blogan> pretty sure the next meeting will have that
16:16:27 <sbalukoff> I'm just catching up on it. Will probably have more to say in gerrit. :)
16:16:39 <rm_work> same
16:16:43 <sballe> same here
16:16:55 <dougwig> current hot points are: client?  governance?  extensions?  core vs service plugins?  dependencies and upgrades
16:17:21 <dougwig> here, or gerrit, or the services meeting in 45 minutes...  feedback anywhere is good.
16:17:41 <sbalukoff> Eeexcellent.
16:18:33 <xgerman_> yeah, need to cathc up with the comments
16:18:40 <dougwig> this topic seems to go dead silent in IRC.  :)
16:18:43 <dougwig> ok, moving on.
16:18:47 <dougwig> #topic Open discussion
16:19:52 <dougwig> any topics to discuss here?
16:19:58 <xgerman_> so this is for the RAX guys -- we would like to get in touch with Miguel to learn more about the tempest tests
16:19:59 <blogan> mind if i talk about Sam's proposal here a bit?
16:20:06 <dougwig> this is my first meeting stateside at the new time.  loving it.  :)
16:20:08 <blogan> after german's
16:20:23 <dougwig> blogan: go for it
16:20:27 <blogan> jorgem sits right next to miguel, though miguel is not always at his desk
16:20:47 <blogan> TrevorV: is miguel there?
16:20:54 <TrevorV> Nope, not right now
16:21:04 <xgerman_> ok, we also send him an e-mail :-)
16:21:08 <TrevorV> I mean he could be in the office today but he's not physically at the desk right now
16:21:14 <blogan> he might be on vacation this week
16:21:20 <xgerman_> ok, that makes sense
16:21:21 <blogan> and he's smart unlike me
16:21:23 <TrevorV> (like blogan should be)
16:21:33 <sbalukoff> Haha
16:21:34 <dougwig> lol
16:21:38 <dougwig> #topic v2 objects as logical models
16:21:51 <dougwig> take it away, blogan
16:22:22 <blogan> other than what i mentioned on the ML, and the fact that it would change v2 midstream, are there any cons to his proposal?
16:22:47 <dougwig> that last is a pretty big con.  city sized.
16:23:20 <blogan> yes but if it is the best most amazing proposal ever, it'd be worth it
16:23:43 <sbalukoff> I would like to see a fleshed-out version of reporting status as well as a state machine description.
16:24:03 <sballe> sbalukoff: +1
16:24:03 <sbalukoff> Once you start sharing objects across entities (ie. not within scope of parent objects), status gets crazy.
16:24:37 <xgerman_> yep, I still fail to understand what sharing gets us -- you can *always* copy objects
16:24:52 <dougwig> if we prep an alternate, i'd like to see other folks working on it, so we're going in parallel and not stalling out.
16:24:54 <blogan> sbalukoff: it does, but the entities will not have statuses directly, they will be statuses only relevant to the parent
16:24:59 <sbalukoff> I'm OK with sharing objects within the scope of parent objects.
16:25:21 <sbalukoff> blogan: Aah-- so there's effectively the built-in scope.
16:25:30 <ptoohill> so the only way to view status is on the parent in this proposal?
16:25:30 <sbalukoff> Ok, that actually makes more sense to me.
16:25:35 <blogan> xgerman_: sharing gets a more intuitive UX for people, they don't have to recreate pools 100 times, and they don't have to update 100 pools
16:25:47 <sbalukoff> ptoohill: Correct.
16:25:59 <xgerman_> well, for the people with a 100 pools -- so that solves a problem for a minority of my users
16:26:06 <blogan> xgerman_: true
16:26:33 <sbalukoff> blogan: It does mean that if I have a pool shared across a bazillion listeners, updating one member initiates a ton of back-end work, any of which could fail.
16:26:34 <ptoohill> So i wouldnt be able to query my members and see their statues, i would have to then query the parent and sort/find through its list of statuses for the members im interested in
16:26:34 <dougwig> sam's proposal fits in especially well with taskflow.
16:26:47 <ptoohill> Not a big deal i suppose
16:27:18 <blogan> sbalukoff: that is true if the backend does not support sharing, but the user will end up manually causing a ton of back-end work anyway if sharing is nto enabled, though it will be easier for the system to handle in that case
16:27:22 <rm_work> ptoohill: you mean like backend nodes?
16:27:32 <ptoohill> or any object really
16:27:37 <ptoohill> was just using that as example
16:27:38 <dougwig> sbalukoff: unless the logical objects are treated as templates, and not real-time config.  (create uses logical structure, edits affect LB tree only.)
16:27:40 <rm_work> ptoohill: I would hope the same doesn't apply to statuses that come from health monitors
16:27:44 <rm_work> blogan: ?
16:27:54 <blogan> ptoohill: if neutorn extensions supported parent child nesting, that would make that easier and I'd like this a lot more
16:28:06 <sbalukoff> dougwig: I don't follow. How is that any different?
16:28:07 <ptoohill> true
16:28:13 <ptoohill> werent they talking about reworking that?
16:28:21 <dougwig> sbalukoff: because then edits to a shared pool would only affect new LB's.
16:28:28 <ptoohill> but thats a ways off even if it was true
16:28:28 <blogan> ptoohill: they're focused on refactoring the API, i think extensiosn will be later
16:28:32 <ptoohill> ah
16:28:47 <blogan> though i need to spend time on seeing if i can hack it to work with the current exntesion loader
16:28:50 <sbalukoff> dougwig:  Aah, I see. That's not very intuitive for the user, though.
16:29:18 <sbalukoff> dougwig: If the user *wants* to affect all load balancers, they're back in the boat of updating everything themselves again..
16:29:20 <dougwig> depends on how it's presented.  it's certainly more in line with the proposal of logical objects being divorced from their provisioned config and status.
16:29:44 <sbalukoff> dougwig: It seems messy to me.
16:29:52 <xgerman_> +1
16:29:56 <sbalukoff> Honestly, I'd rather initiate all that back-end work.
16:29:58 <blogan> that does remove half the reason to have shared objects in that updating one entity can update many
16:30:13 <sbalukoff> blogan: That's my perception of its benefit, too.
16:30:27 <xgerman_> and my fear of support calls.
16:30:34 <blogan> dont fear the reaper
16:30:51 <sbalukoff> Oh, pshaw. Providing customer support is so 2014.
16:31:00 <rm_work> <_<
16:31:06 <dougwig> what company would be silly enough to bet on fanatical support?
16:31:07 <dougwig> oh.
16:31:10 <sbalukoff> Haha
16:31:15 <dougwig> :)
16:31:17 <blogan> some insane company
16:32:01 <xgerman_> well, I am not sure how Sam's proposal will make development easier + we can solve his use cases by copying stuff
16:32:14 <sbalukoff> Ok, so... again, I want to see the idea fleshed out more, as well as some discussion of handling various scenarios (what I mean by state machine, I guess).
16:32:24 <dougwig> does someone want to chase this down and ferret out if it's good enough to overturn the boat?  blogan, before you answer, you are supposed to be on vacation.
16:32:44 <sbalukoff> And I would like to see logical objects nested under parent objects as blogan says.
16:32:47 <blogan> im pretty sure sbalukoff already asked for this on the ML
16:32:50 <sbalukoff> Otherwise, I don't have a problem with this in theory.
16:32:56 <xgerman_> sbalukoff +1
16:33:12 <dougwig> so ,we wait for an ML response and table this for a week or two?
16:33:14 <xgerman_> nesting objects is goog
16:33:14 <sballe> sbalukoff: +1
16:33:32 <sbalukoff> dougwig: Yep.
16:33:41 <blogan> sounds good to me, hopefully sam responds with such
16:33:48 <sbalukoff> dougwig: With all the advanced services stuff in the works, I wonder how much traction we'd have overturning the boat.
16:33:49 <blogan> evgenyf: you around?
16:33:57 <sbalukoff> Though it seems Radware / Samuel would be on board.
16:33:57 <dougwig> ok.  i'd say we should go ahead with the v2 spec, and add this later if it bears fruit.
16:34:03 <evgenyf> blogan: yes
16:34:23 <sballe> dougwig: +1
16:34:28 <sbalukoff> dougwig: +1
16:34:43 <blogan> evgenyf: could you relay to sam, if he doesn't know yet, that we'd like more fleshed out examples
16:34:56 <evgenyf> Sure
16:35:10 <blogan> thanks!
16:35:15 <dougwig> #topic Open discussion
16:35:18 <dougwig> anything else this morning?
16:35:32 <blogan> evgenyf: unless you can provide the examples
16:35:40 <sbalukoff> Have a happy turkey day, for those who celebrate it?
16:36:06 <blogan> i thought this week was happy rioting day
16:36:09 <blogan> or week
16:36:15 <dougwig> settle down.
16:36:20 <sbalukoff> It's turning into riot week.
16:36:22 <sbalukoff> Haha
16:36:41 <dougwig> on that note, let's get out of here.  thanks, everyone.
16:36:46 <blogan> lol
16:36:46 <sballe> bye
16:36:48 <rm_work> see you all next week :)
16:36:49 <xgerman_> thanks -- see you in 24
16:36:50 <blogan> bye
16:36:50 <sbalukoff> Thanks! Seeya!
16:36:56 <dougwig> #endmeeting