14:01:55 <jorgem> #startmeeting neutron lbaas
14:01:55 <xgerman> mmh\
14:01:55 <openstack> Meeting started Thu Aug  7 14:01:55 2014 UTC and is due to finish in 60 minutes.  The chair is jorgem. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:59 <openstack> The meeting name has been set to 'neutron_lbaas'
14:02:27 <rm_work> o/
14:02:37 <jorgem> Here is the agenda for today #link https://wiki.openstack.org/wiki/Network/LBaaS#Agenda
14:03:35 <jorgem> #topic Review Updates
14:03:46 <blogan> mestery: are you present?
14:04:06 <jorgem> Someone added "review politicking"
14:04:10 <blogan> I did!
14:04:18 <sbalukoff> Heh!
14:04:30 <sbalukoff> blogan is an honest man.
14:04:33 <ptoohill> hello
14:04:35 <jorgem> go ahead blogan
14:04:41 <jorgem> hi ptoohill
14:04:44 <blogan> well i was hoping mestery would be here
14:05:01 <xgerman> we need to summon him somehow
14:05:15 * dougwig casts Summon PTL
14:05:48 <dougwig> he might still be sick.
14:05:50 <blogan> but since he's not, we need to get more clarity on how to get this merged in and with all this GBP talk, will we follow the same path that is decided with that?
14:06:05 <jorgem> well why don't we wait until he is summoned and move this topic to the end of the meeting for now
14:06:17 <dougwig> the short form is, keep reviewing.  we're all worried that with review load, v2 won't get reviewed in time.  notice the gob thread, same issue.
14:07:07 <xgerman> well, then we take our ball and play somewhere else
14:07:55 <jorgem> okay next topic until mestery is summoned
14:08:00 <jorgem> #topic Separating deployment and operational status
14:08:46 <dougwig> i'd like to point out up front that the outcome of this should be expected for kilo, not juno.
14:08:47 <blogan> this one is pretty simple, its just the fact separate status fields are needed for different types of statuses
14:09:02 <blogan> dougwig: yes indeed
14:09:03 <xgerman> +1
14:09:11 <sbalukoff> Yep, agreed. Also agreed on Kilo timeframe.
14:09:25 <blogan> so which entities have the operational status?
14:09:45 <blogan> pool and members?
14:09:45 <xgerman> all?
14:10:03 <vjay> listener, pool and members?
14:10:08 <sbalukoff> Yea, you can have an operational status for listener, too.
14:10:10 <dougwig> pool, member, listener, and lb would be my take.
14:10:35 <vjay> what would lb operational status reflect?
14:10:40 <sbalukoff> And yes, LB as well.
14:10:49 <dougwig> if all listeners are dead (or some minimum number)
14:10:53 <sbalukoff> "Is the VIP deployed on anything"
14:11:06 <vjay> VIP deployed ins deployment status
14:11:10 <jorgem> how about ONLINE, OFFLINE for operational statuses?
14:11:13 <vjay> s/ins/is
14:11:20 <jorgem> that seems clearer to me
14:11:40 <jorgem> ACTIVE is already part of deployment statuses
14:11:51 <blogan> im fine with offline/online
14:11:59 <dougwig> i think we want a longer list, or a description field for more detail (i.e. slow response, expired cert, ...)
14:12:03 * mestery stumbles in, but has been down with a nasty cold this week ...
14:12:08 <vjay> would it be helpful to say DEGRADED as well in operational status?
14:12:12 <xgerman> I like ERROR, too
14:12:13 <dougwig> o/ mestery
14:12:31 <jorgem> hi mestery! While we have you let's go back to our  first topic
14:12:40 <mestery> jorgem: ack
14:12:42 <jorgem> thank you for joining
14:12:50 <xgerman> mestery o/
14:12:54 <jorgem> #Topic Review politicking (How likely is v2 to actually get merged in?)
14:13:06 <jorgem> blogan: the floor is yours again
14:13:26 <blogan> mestery: some of us are getting a bit worried that v2 may not have enough time to get reviewed thoroughly to get in
14:13:32 <blogan> mestery: what is your take on it?
14:13:46 <mestery> blogan: I think from a review perspective, we have enough runway, as we can ramp people.
14:13:57 <mestery> I think the larger concern is the GBP discussion, and how that might afffect LBaaS V2
14:14:07 <blogan> mestery: also it seems there are corrolations to be made between the GBP talk and the lbaas v2 API
14:14:10 <mestery> blogan: ++
14:14:25 <mestery> I'm working on a solution to both of these (LBaaS v2 and GBP) issues now.
14:14:38 <blogan> is it safe to assume we will both share the same fate?
14:14:50 <mestery> blogan: That seems pretty likely, yes.
14:15:22 <dougwig> anything we can do in the meantime, or are we stuck in gerrit limbo?
14:15:24 <mestery> One idea we've had is to create a new git repository under the networking program for experimental APIs
14:15:30 <mestery> With a clear path on how to graduate into the main neutron repo
14:15:45 <mestery> That woudl allow for fast iteration and reviews there, with a path forward into neutron.
14:15:51 <mestery> It's an early idea, but something we're thinking about.
14:16:06 <mestery> The alternative is to have the experimental directory be directly in the neutron tree I think
14:16:16 <xgerman> +1
14:16:25 <sbalukoff> I take it that path wouldn't be subject to the whole "no 5000-line commits" rule of thumb?
14:16:42 <mestery> sbalukoff: ++
14:17:01 <blogan> mestery: i assume neutron core will still be responsible for reviewing every commit in the experiemental apis, in neutron tree or outside?
14:17:25 <mestery> blogan: Yes, that's the plan.
14:17:41 <mestery> But hopefully we can iterate faster there, and the part we need to nail down is the clear path into the main repo.
14:17:51 <blogan> mestery: so if it is outside the tree, it would still require neutron core +2's to get into that outside tree?
14:18:05 <jorgem> or have separate +2's?
14:18:13 <dougwig> neutron does have this schizophrenic split of needing to be mature/stable and also needing to gofastgofastgofastgofast.  a function of its rather broad mandate.
14:18:15 <mestery> blogan: That was the initial thought, because it would be under the networking program still
14:18:23 <mestery> dougwig: Exactly
14:18:42 <mestery> To be honest, this was something we were looking at proposing in Kilo, we may need to expedite the plans now.
14:19:16 <jorgem> mestery: How would velocity increase if there is a limit on the core reviewers time? I feel the core reviewers have a lot on their plates.
14:19:38 <mestery> jorgem: That's a valid concern, and perhaps we give some additinoal people +2 on the experimental repo, maybe one from each project, etc.
14:19:41 <mestery> That would most certainly help
14:19:47 <blogan> mestery: I think i misunderstood that projects under the networking program that were not in neutron would be able to self-govern themselves
14:19:59 <jorgem> mestery: Okay one additional +2 on each project makes sense
14:20:00 <dougwig> jorgem: just a guess, but a dedicated experimental area likely has less stringent review requirements than a stable base.
14:20:06 <xgerman> so we are talking lbaas being spun out here
14:20:08 <xgerman> ?
14:20:35 <mestery> xgerman: Not spun out, but put into an incubator for eventual inclusion.
14:20:46 <mestery> Again, I should stress we're just discussing this now, we haven't come to a firm conclusion yet.
14:20:55 <mestery> But getting the LBaaS team's feedback woudl be good
14:20:55 <blogan> dougwig: if the goal is to get into neutron tree, and the reviews are less stringent, then that means when it is time to get back into the neutron review it'd be like the neutron cores had to review one massive patch
14:21:04 <xgerman> ok, with own reviewers + own repo it feels pretty autonomous :-)
14:21:13 <jorgem> mestery: If anything someone will be decided by next summit I'm 'thinking?
14:21:25 <jorgem> something*
14:21:33 <dougwig> blogan: not less stringent overall, but more flexible to, "this is incomplete, but throwing it in here increases iteration velocity, and fixed in a followup".  more of a smaller company mindset.
14:21:38 <dougwig> i'm not sure i'm communicating that well.
14:21:42 <mestery> jorgem: I think we need to decide by next week if we try to do this, so lets see.
14:21:49 <jorgem> mestery: gotcha
14:21:51 <mestery> dougwig: ++
14:22:01 <mestery> It's almost like the linux kernel model of development
14:22:04 <mestery> A tree hiearchy
14:22:08 <mestery> with lieutenants at each level
14:22:16 <mestery> so that when it lands to neutron, it's already in a pretty good state
14:22:18 <jorgem> mestery: I think for LBaaS we shouldn't do this for Juno since we tried to do this already to a degree.
14:22:19 <mestery> It has tempest tests, etc.
14:22:35 <blogan> I feel like it could end up in being the stringent reviews get kicked down the road until its time to get into teh tree, and then when that time comes, reviews take even longer because there is a whole new API to review in full
14:22:37 <mestery> jorgem: Understood, completely agree.
14:22:38 <jorgem> mestery: It kind of defeats the hackathon and everything we did
14:22:58 <xgerman> bloga n +1
14:23:03 <jorgem> sure one could treat it as a sunk cost but we all have deadlines on our side as well
14:23:04 <mestery> jorgem: I understand, like I said, this is mostly something we're thinking on.
14:23:06 <xgerman> jorgem +1
14:23:26 <jorgem> What's everyone else thinking?
14:23:27 <mestery> So, I'll keep you all posted on the discussions here.
14:23:40 <jorgem> eveyone = lbaas people
14:24:02 <xgerman> jorgem, as I said experimental area is like 50% spun out...
14:24:11 <dougwig> blogan: well, something has to change.  we complain that neutron is review bottlenecked, bounce around alternatives, and the final consensus always seem to be, "keep it in tree, and just work smarter!"  and i'm not pointing the finger at just lbaas for that discussion model, look at how the community responded to mark's gbp proposal as well.  and all the
14:24:11 <dougwig> others.  something *has* to change structurally.
14:24:20 <sbalukoff> It's going to be severely diappointing not to see the LBaaS work we've done end up in Juno.
14:24:28 <jorgem> xgerman: true but we almost have code in neutron code base which is the goal here.
14:24:56 <xgerman> sbalukoff +1
14:24:58 <jorgem> spinning out to get it in to neutron is one step back then forward again
14:25:14 <xgerman> sadly, yes -- experimental area is a half step
14:25:47 <blogan> in my opinion, i like the idea of it, if executed correctly it woudl be better for neutron stability and increase velocity, im just thinking of worst case scenario and common human behavior
14:26:06 <johnsom_> I hope the process for getting code promoted is clear and well understood.
14:26:18 <xgerman> +1
14:26:18 <jorgem> So I'm guessing it's safe to say that the LBaaS community would like to get the code into Juno? Thus, this means not becoming experimental. Does anyone disagree?
14:26:30 <rm_work> I'm not a huge fan, for reasons blogan already mentioned (kicking the stone down the road)…
14:26:44 <xgerman> yep, we like to be grandfathered
14:26:54 <sbalukoff> xgerman: +1
14:26:56 <dougwig> jorge: i'm not a fan of pretending we can squeeze the stone harder and make water appear
14:26:56 <vjay> jorgem: +1
14:26:57 <jorgem> xgerman: +1
14:27:32 <jorgem> dougwig: The idea is sound but I think we should be grandfathered in for the work we have completed thus far
14:27:36 <mestery> OK, I need to go back to bed now, thanks for listening and I'll keep everyone updated here!
14:27:37 <sbalukoff> dougwig: I'm not entirely sure it's a stone just yet. But it's certainly getting harder.
14:27:46 <jorgem> mestery: thanks get better!
14:27:54 <mestery> jorgem: Thanks!
14:28:00 <blogan> mestery: thanks
14:28:04 <xgerman> mestery: thanks
14:28:07 <sbalukoff> Thanks!
14:28:10 <dougwig> we have a very long review chain, more coming, and iterations we want/need to do on top of that.  i'm not sure wishing all of that into juno is realistic (if it is, great.)
14:28:29 * blogan casts banishment spell on mestery
14:28:38 <dougwig> thanks mestery, feel better
14:28:54 <jorgem> dougwig: Perhaps define which items to grandfather and which to not???
14:28:57 <blogan> dougwig: i agree with you, seeing is believing on the reviews getting in
14:29:09 <jorgem> dougwig: If, of course, the community moves in that direction
14:29:16 <xgerman> yeah, we should make a prioritized list
14:29:27 <xgerman> of changes to approve
14:30:04 <dougwig> i would rather increase velocity and have to do "apt-get install neutron-lbaas" than pretend there is no problem and get punted to kilo.  we have a lot of reviews, but at the end of the day, it's kind of a big lump pill to swallow; it doesn't slice up well.
14:30:40 <tmc3inphilly> Let me see if i get this straight, some do not want it in Neutron for Juno, yet they do not want to spin it out on its own?  Are we talking code pergatory?
14:31:03 <dougwig> i think we all want it in neutron for juno.
14:31:12 <dougwig> we're just talking damage control at this point.
14:31:16 <sbalukoff> dougwig is just trying to be reasonable.
14:31:26 <sbalukoff> I say we throw a temper tantrum and see where that gets us. ;)
14:31:28 <xgerman> I have no problem with being unreasonable
14:31:44 <samuelbercovici> sbalukoff:to whom?
14:32:18 <tmc3inphilly> it isn't like we are going to check in 87878787878787 lines of code for each release right?  This is a temporary problem for this release.
14:32:26 <jorgem> Okay, I guess we can join the HUGE ML thread on this.
14:32:55 <xgerman> I only read things tagged with [LBAAS]
14:32:57 <jorgem> There are obviously a lot of opinions and concerns so maybe we can address them there?
14:32:58 <rm_work> xgerman: +1, I was *born* to be unreasonable
14:33:00 <sbalukoff> There's a lot of politicking going on in that thread. :/
14:33:05 <dougwig> tmc3inphilly: think of the unfinished reviews we have for just juno: driver agent, full tis support, l7 routing, driver shim, horizon support
14:33:38 <blogan> dougwig: i abandoned the shim beacuse it wasn't complete and work stopped on it completely
14:33:44 <jorgem> Everyone okay with moving to next topic?
14:33:48 <blogan> yes
14:33:55 <xgerman> +1
14:33:57 <blogan> come back to this when mestery gets more details
14:34:01 <jorgem> #topic Separating deployment and operational status
14:34:11 <xgerman> or we get blogan to be neutron core :-)
14:34:13 <dougwig> blogan: right, exactly my point that we're nowhere near done with the v2 refactor.  it's not like we have some known quantity to shove into juno and we're done with neutron reviews forever.
14:34:13 <jorgem> K, anything else on statuses?
14:34:13 <sbalukoff> By the way, the 'throw a temper tantrum' comment was tongue in cheek.
14:34:34 <sbalukoff> (Written medium, sarcasm doesn't translate well. Sorry.)
14:35:03 <blogan> sbalukoff: i could you see you throwing a tantrum
14:35:14 <xgerman> blogan +1
14:35:21 <sbalukoff> To be honest, I think status is going to have to be expanded upon when we start to have shared entities. But I don't think we necessarily need to solve that problem now.
14:35:22 <dougwig> +1
14:35:56 <sbalukoff> In any case, there's definitely a need for operational and deployment status to be separate.
14:36:04 <xgerman> we should also get in line with the other stauses in Neutron
14:36:18 <jorgem> xgerman: unless we are experimental!
14:36:20 <blogan> xgerman: could you elaborate?
14:36:46 <xgerman> I think we need to research what firewall, etc. are doing to not confuse users
14:37:09 <jorgem> xgerman: fair enough
14:37:26 <blogan> i don't even know if they are async APIs
14:37:37 <blogan> so yes more research
14:37:42 <blogan> +1 xgerman
14:37:50 <samuelbercovici> we have started this discussion at the beginnign of the cycle and decided to push it for K and to not share objects. I think this is still a good choice
14:38:08 <dougwig> i think at the meetup mark also suggested a potential strategy of adding stats() everywhere and adding some operational details to it.
14:38:13 <dougwig> samuelbercovici: +1
14:38:14 <samuelbercovici> is there a reason to open this before K?
14:38:17 <blogan> samuelbercovici: this won't happen in Juno at all, its just a discussion for what to do in K
14:38:33 <jorgem> Okay let's move on to Juno items then?
14:38:39 <vjay> sure
14:38:44 <jorgem> #topic Calling driver interface on every API request
14:39:12 <sbalukoff> blogan actually elaborated on why this isn't practical in the openstack-lbaas channel a couple days ago.
14:39:23 <sbalukoff> Care to repeat, blogan?
14:39:32 <blogan> sbalukoff yes
14:40:08 <blogan> currently its not practical because the loadbalancer entity is what decides what driver to go to
14:40:44 <blogan> so if something is not linked to a loadbalancer, there's no way to know what driver to go to, and since we support multiple providers/drivers then we can't get around this
14:40:59 <sbalukoff> And in the future it still won't be practical because loadbalancer entity in conjunction with flavor and service_profile will determine that. :)
14:41:06 <vjay> ok. that explains a lot.
14:41:08 <blogan> however, if we link all entities to a provider/driver individually, then this can be done
14:41:18 <blogan> yeah just substitute provider/driver with flavor
14:41:31 <sbalukoff> And that seems like a bad idea from a portability perspective to me.
14:41:58 <vjay> just thinking out loud, is it ok to create entities with respect to a loadbalancer/listener
14:42:10 <blogan> sbalukoff: i've thought of some pros and cons to this, but more thought needs to be put into it
14:42:32 <sbalukoff> blogan: I'd love to hear those pros and cons. :)
14:42:46 <sbalukoff> vjay: What do you mean?
14:42:48 <blogan> vjay: what do you mean?
14:42:52 <blogan> lol
14:43:13 <vjay> instead of creating pool as an independent entity
14:43:25 <vjay> can it have a listener or loadbalancer id?
14:43:33 <blogan> sbalukoff: you put me on the spot i had pros of it when i was thinking about it last night but its too early for me, and they were really good pros, I PROMISE!
14:43:59 <dougwig> you mean have a required root object?  i'd love that.  the community wanted all the entities to be independent root objects for some reason.
14:43:59 <xgerman> take notes of your ideas :-)
14:44:02 <sbalukoff> vjay: That puts us in a position where introducing shared objects later is going to be problematic.
14:44:14 <blogan> vjay: currently it cannot, and the reason the pool_id is on the listener is for the plan in the future to allow 1:M listener to pool relationship
14:44:55 * vjay thinking
14:45:05 <sbalukoff> Is it really that hard to create / update all those objects at once, once we finally have an association with a load balancer?
14:45:21 <xgerman> sba;ukoff +1
14:45:26 <rm_work> dougwig: SOME of the community wanted that
14:45:36 <vjay> i think it boils down to definition of pools
14:45:43 <rm_work> we wanted everything to be under a LB object, IIRC :P
14:45:50 <vjay> if pool is considered as a collection of members.
14:45:59 <vjay> not associated with a loadbalancer
14:46:18 <dougwig> sbalukoff: no, but it does add a fair bit of code complexity up and down the chain.  that means added bugs, for currently no gain (my bias is leaking again.)
14:46:24 <vjay> then for ex. the stats should be retain when a pool is attached and reattached to another loadbalancer
14:46:26 <rm_work> yeah, I kinda thought we weren't even trying to create anything until it was linked to a listener / LB and was ready to serve traffic
14:46:33 <rm_work> I don't see the point of provisioning anything before that
14:46:46 <xgerman> +1
14:47:02 <samuelbercovici> +1
14:47:15 <dougwig> rm_work: that's a driver decision.  as long as you know which driver, which was the ultimate reason we defer.
14:47:23 <sbalukoff> vjay: It might not be useful to retain stats on a 'per pool' basis if the pool can be shared. :/
14:47:26 <rm_work> :(
14:47:28 <crc32> +1
14:47:48 <sbalukoff> As in, it might make sense to have stats on a pool only within the context of a loadbalancer + listener.
14:47:48 <blogan> sbalukoff: i agree on that, though i know people have wanted stats per pool
14:47:55 <samuelbercovici> sbalukoff: recall my proposal on how to persist status and stats
14:48:03 <sbalukoff> In which case, you don't need to retain stats for a pool in the long run across config changes.
14:48:30 <xgerman> stats per pool won't work if a pool is attaced to more than one listener
14:48:33 <sbalukoff> samuelbercovici: Sorry I've forgotten that proposal (I have a terrible memory)
14:48:48 <dougwig> xgerman: sure they will.  they'll just be additive.
14:48:52 <vjay> also, lets say if driver does not support a certain aspect of a child entity. for ex. some monitor protocol is not supportted. The driver will thrown an error during create of listener, than create of monitor.
14:48:58 <sbalukoff> xgerman: Or, it becomes a dictionary, which probably has less meaning to an end user
14:49:18 <dougwig> vjay: oh, that's an interesting point.
14:49:25 <blogan> samuelbercovici: you mean having all the stasuses of children enetities on the loadbalancer?
14:49:25 <sbalukoff> vjay: Deployment errors should be bubbled up, IMO.
14:50:00 <jorgem> if we have stats on a listener object, why can't you add the listener stats to get pool stats (assuming shared pool)?
14:50:13 <dougwig> vjay: that would work today, but blogan, that's a reason to be careful about automatic driver status.
14:50:23 <jorgem> if the user really wanted that (I don't no why) they could easily do it.\
14:50:45 <jorgem> T - 10 mins
14:51:04 <xgerman> yeah, we might need to defer that to the ML
14:51:13 <vjay> ok.
14:51:24 <vjay> there is still one more item in the agenda
14:51:27 <jorgem> okay last topic of the day
14:51:37 <jorgem> #topic Octavia Update
14:51:41 <jorgem> sbalukoff: ?
14:51:47 <dougwig> i just wanted to do this:
14:51:50 <dougwig> #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/042232.html
14:52:14 <jorgem> dougwig: Thanks.
14:52:21 <blogan> yeah I don't think octavia should be discussed here, unless it deals with integrating octavia with neutron lbaas
14:52:24 <blogan> that is my opinion though
14:52:31 <jorgem> I guess we are done then unless anyone has something else to bring up.
14:52:31 <blogan> since octavia has its own meeting
14:52:44 <jorgem> Anything else?
14:52:58 <blogan> do we have any action items?
14:53:03 <sbalukoff> Um... octavia update?
14:53:13 <blogan> sbalukoff: ^^^
14:53:15 <sbalukoff> blogan +1
14:53:16 <jorgem> #action Read up on the Neutron ML thread (everyone)
14:53:34 <jorgem> haha okay well that's wraps it up then.
14:53:37 <jorgem> Thanks for playing!
14:53:42 <xgerman> should we make reseraching stsatus in advanced services an action item?
14:53:42 <blogan> bye everyone
14:53:44 <sbalukoff> Thanks, y'all!
14:53:49 <rm_work> o/
14:53:49 <jorgem> #endmeeting