14:00:48 <mestery> #startmeeting neutron_lbaas
14:00:50 <openstack> Meeting started Thu May 22 14:00:48 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:53 <openstack> The meeting name has been set to 'neutron_lbaas'
14:01:17 <mestery> Does anyone know if blogan will be joining soon? A lot of the agenda came from him. :)
14:01:39 <dougwig> he's probably hunting down caffeine.
14:01:40 <mestery> #link https://wiki.openstack.org/wiki/Network/LBaaS#Meeting_22.05.2014 Agenda
14:01:42 <s3wong> enikanorov not here?
14:01:45 <ptoohill> He should be jumping in here shortly
14:01:50 <ptoohill> blogan that is
14:01:51 <rm_work> enikanorov is on vacation still
14:01:52 <mestery> ptoohill: dougwig: Thanks!
14:02:00 <mestery> Yes, enikanorov is still on vacation this week.
14:02:35 <mestery> OK, lets get started here then while we wait for blogan to join.
14:03:00 <mestery> #topic Updated Object Model Blueprint
14:03:05 <mestery> #link https://review.openstack.org/#/c/89903/
14:03:16 <mestery> blogan has updated enikanorov's BP, I encourage everyone to review this.
14:03:38 <mestery> Getting this reviewed and approved will be good to have done by early next week.
14:04:11 <mestery> The changes should reflect the discussions we had last week in Atlanta as well, along with all the emails and documents shared over the past few months.
14:04:36 <mestery> I encourage folks to read that offline and discuss in the review itself.
14:05:03 <sbalukoff> Okeedokee
14:05:23 <mestery> blogan: Welcome!
14:05:28 <blogan> mestery: thanks
14:05:39 <mestery> blogan: I just pointed folks to your spec.
14:05:50 <mestery> blogan: Encouraged discussion on the spec itself.
14:06:00 <mestery> samuelbercovici: Howdy!
14:06:09 <mestery> For those who just joined:
14:06:11 <mestery> #link https://review.openstack.org/#/c/89903/
14:06:13 <blogan> ah great, yeah i'm sure i got some things wrong so please comment on it
14:06:31 <sballe> blogan, Is it totally up to date will at the latest changes?
14:06:32 <samuelbercovici> hello eveyone...
14:06:40 <sballe> hi sam
14:06:48 * mestery waves at samuelbercovici
14:07:20 <xgerman_> hi
14:07:21 <samuelbercovici> was the group photo published anywhere?
14:07:33 * mestery waits for blogan to answer sballe.
14:07:33 <rm_work> oh yeah! I wanted that :)
14:07:41 <blogan> you mean the 500 group photos?
14:07:42 <sballe> not yet. Julian is working on it
14:08:14 <blogan> sballe: sorry, it is
14:08:29 <blogan> sballe: actually it does not contain the API changes, just the object model
14:08:47 <sballe> blogan, thx. I will take a look and comment.
14:08:52 <blogan> sballe: I've left that to be done in another blueprint so this one can focus on getting the object model correct and making sure the existing API works with it
14:09:07 <mestery> blogan: +1 to that
14:09:15 <sballe> blogan, 100% agree
14:09:27 <mestery> OK, should we move on to the next agenda item?
14:09:58 <blogan> sure since people will need tiem to look over that blueprint and comment
14:10:04 <mestery> Agreed blogan
14:10:12 <mestery> #topic Creation Workflow with new API
14:10:18 <sballe> before we do can we get commitement form at least one person from each company/group to review the bp?
14:10:28 <mestery> #undo
14:10:28 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x3a1e4d0>
14:10:36 <mestery> sballe: I think that's fair.
14:10:52 <samuelbercovici> sballe: I will review next week
14:10:54 <sballe> I would like to set a date and say after that date you have lost your vote
14:11:02 <sballe> if you haven't reviewed
14:11:04 <sbalukoff> I'll review early next week as well.
14:11:18 <dougwig> i'll look this week.
14:11:26 <xgerman_> me too
14:11:28 <sballe> ok so a deadline of May 29?
14:11:33 <mestery> sballe: How about by next Thursday?
14:11:51 <sballe> May 28? +1
14:11:53 <blogan> sballe: i think the core reviewers will need to look at it as well and be sure there aren't any major issues with it from their perspective
14:12:04 <rm_work> will enikanorov be back and able to review by then too?
14:12:07 <mestery> #action LBaaS team to review https://review.openstack.org/#/c/89903/ by May 28.
14:12:14 <mestery> blogan: Yes, that will happen in parallel.
14:12:23 <blogan> mestery: ok great
14:12:27 <sballe> mestery, please add core reviewers to thta as well
14:12:29 <mestery> rm_work: I'll talk to him early next week to confirm.
14:12:36 <mestery> sballe: Yes, I will do that.
14:12:51 <mestery> The sooner people review, the faster blogan can iterate on this. :)
14:13:00 <sballe> mestery, blogan +1
14:13:19 <mestery> OK, lets move on to the next topic then.
14:13:30 <sballe> ok
14:13:45 <crc32> ok
14:13:47 <mestery> #topic Creation Workflow with new API
14:13:56 <mestery> Please see the agenda, but blogan has proposed some changes here.
14:14:08 <mestery> blogan: Can you explain to the group briefly?
14:14:23 <blogan> well its more of a discussion on this and it comes down to what is considered the root object
14:14:34 <blogan> so in the new API I've always considered the root object to be the load balancer
14:15:07 <blogan> but I'm not sure if others think the root object should be created first, and with the new API I don't think it makes sense to have the load balancer created first, it should be created last
14:15:38 <sbalukoff> I don't see why either order wouldn't be valid.
14:15:41 <samuelbercovici> why do we need an order?
14:15:51 <crc32> no single call?
14:15:52 <samuelbercovici> sbalukoff:+1
14:15:55 <rm_work> it comes down to what triggers actual provisioning, right?
14:15:56 <sbalukoff> In my mind, a user should be able to create the individual objects in whatever order they want.
14:16:05 <blogan> well maybe we don't but at the summit meeting, soemoen asked the order and no one could really answer it
14:16:10 <dougwig> different vendors may require different orders.  as long as the objects hang together at the end, what is the issue?
14:16:14 <sbalukoff> crc32: Single call should still happen through 'loadbalancer'
14:16:34 <rm_work> crc32: i think the plan is to do that as a second step, after we get the individual stuff working
14:16:43 <mestery> So the consensus appears to be order doesn't matter here, right?
14:16:49 <blogan> single call should happen in another blue print after this is locked down
14:16:49 <samuelbercovici> +1
14:16:56 <mestery> blogan: +1
14:17:01 <rm_work> so, if order doesn't matter, what triggers a "GO" for provisioning?
14:17:15 <dougwig> it'd be safer to say that order matters to a given implementation, and it's not an interface/model question.
14:17:21 <samuelbercovici> the driver should decide when it has enough information to GO
14:17:23 <sbalukoff> rm_work: Once you have a loadbalancer and an associated listener, that's "GO"
14:17:25 <rm_work> I had assumed it would be: create all sub-objects and link them up, and when you're ready, create the LB object
14:17:41 <rm_work> sbalukoff: yeah, that makes sense
14:17:41 <samuelbercovici> sbalukoff: that should be fine for now
14:17:59 <samuelbercovici> but this is still a diver decision
14:18:00 <crc32> ok but when some one says the loadbalancer is not creted first and if loadbalancer is root object then via implication single calls break.
14:18:01 <rm_work> so then, you create the LB with no listener associated, then update it to link one when you're ready?
14:18:11 <blogan> so is my understanding of other people's understanding of what a root object wrong here?
14:18:26 <rm_work> crc32: i'm not sure why that'd be the case
14:18:31 <xgerman_> I like things to be explicit so the user gets an error message, e.g. no listener
14:18:33 <mestery> rm_work: That was blogan's first propsal in the agenda, yes.
14:18:45 <rm_work> alright, i guess that works
14:18:53 <dougwig> is the single create something new for juno?  because right now, you have to create a pool before associating a vip, e.g.
14:18:57 <sballe> xgerman_, +1
14:19:01 <rm_work> dougwig: yes
14:19:08 <mestery> dougwig: yes
14:19:34 <sbalukoff> I'm not sure I like that:  You're essentially saying a loadbalancer must always have a listener associated with it.
14:19:57 <rm_work> sbalukoff: which makes sense if it is created last always, but not otherwise <_<
14:19:57 <rm_work> so yeah
14:19:58 <sbalukoff> So that having at least one listener is a non-optional attribute in the loadbalancer create call?
14:20:01 <dougwig> is there a bp for the goal that we're trying to achieve here?
14:20:12 <crc32> rm_work: A single call create would create a loadbalancer but others are saying a loadbalancer is not created first therefor the load balancer create is at least the second call or greater. Do you understand that?
14:20:46 <rm_work> crc32: i see no hard technical reason that'd be the casse, no
14:20:48 <rm_work> *case
14:21:22 <blogan> i would say leave the single call out of this right now and just talk about the granular calls
14:21:29 <mestery> dougwig: We're starting with the object model BP referenced earlier. The team has generated lots of google docs over the past few months, I'd encourage catching up on the mailing list archives.
14:21:30 <ptoohill> crc32 I believe this is talks without the single call at this point
14:21:33 <rm_work> single call could essentially create all sub-objects first in the background then create the LB with them attached, same as the singular workflow -- difference being, it is internal to the service so there is not multiple round-trips necessary :)
14:21:33 <blogan> the single call should be easy enough to accomplish
14:21:50 <mestery> blogan: +1
14:22:04 <crc32> yea I'll explain that "2" comes after 1 to adam later.
14:22:07 <rm_work> we're leaving it till later, yes -- but crc32 has a point in that if he was right, it would affect single-call design
14:22:47 <blogan> so what are yall advocating?
14:22:56 <rm_work> fortunately he's not right
14:22:56 <dougwig> i'm guessing you have to send extra info to the api for the single call, which implies you'd also need to send extra info to the driver, at which point order becomes moot, doesn't it?  it's the driver's call how to order it.
14:22:58 <rm_work> so it's fine
14:23:05 <rm_work> dougwig: right
14:23:06 <sbalukoff> I've yet to hear a reason why we shouldn't support a load balancer object existing independent of any associated listeners.
14:23:18 <rm_work> sbalukoff: no real hard technical reason, correct
14:23:40 <mestery> I think we're all in violent agreement here. :)
14:23:48 <xgerman_> +1
14:23:52 <sbalukoff> So, if there's no technical reason, why enforce this restriction?  Let the driver decide when to schedule actually deployment of services.
14:23:59 <blogan> sbalukoff: there isn't other than the minor issue of when to actually provision the load balancer, but thats trivial to overcome
14:24:00 <sbalukoff> Haha!
14:24:09 <rm_work> sbalukoff: i agree, it's fine. +1
14:24:24 <xgerman_> by making provisioning explicit you make it easier for the user to figure out what he missed
14:24:40 <xgerman_> otherwise he creates stuff and wonders why no lb appears
14:24:52 <mestery> xgerman_: That's true, it's a user experience thing.
14:25:05 <blogan> yeah i could see how a user would wonder why after creating a load balancer through the API, they don't actually have a load balancer
14:25:21 <samuelbercovici> if there was an implicit action on the lb named "provision"
14:25:21 <rm_work> I mean, if i were doing a multi-call create, *I* would still do the LB last and explicitly link the listener there, definitely
14:25:25 <samuelbercovici> ?
14:25:54 <rm_work> samuelbercovici: interesting, though I could see THAT breaking single-call :)
14:26:05 <rm_work> since it would be inconsistent then to provision instantly
14:26:23 <samuelbercovici> rm_work: actualy single call would populate the database object in whatever order and do provision
14:26:29 <sbalukoff> So, the problem I have with creating the load balancer last (and enforcing this behavior) is because you will defintiely be following a different work flow when adding a second listener to an existing load balancer.
14:26:35 <rm_work> right, but that'd be inconsistent, no?
14:26:50 <mestery> OK, I'm wondering if we're wandering a bit here. The main focus was on creation order, and I think we've all agreed on that particular point, right?
14:27:07 <xgerman_> yep
14:27:10 <rm_work> in the multi-call case, you would have a fully fleshed out LB and it would not be provisioned until you said to provision it, but with single call you'd have the same thing and it would auto-provision
14:27:11 <sbalukoff> mestery: If "It doesn't matter" is the agreement, then I agree. :)
14:27:17 <sballe> mestery, please summarize what are in agremment on
14:27:28 <blogan> mestery: as long as people are willing to accept that the user experience may not be as good as possible and allowing any order is fine, then we are all in agreement
14:27:33 <mestery> sbalukoff: I was under the impression that was the agreement, but I may be confused.
14:27:33 <xgerman_> +1 rm_work
14:28:03 <sballe> blogan, Hey lets' stop here. The reason we are redoing the API etc is becasue of the user experience
14:28:08 <mestery> rm_work: If that's the main difference, I think it satisfies everyone's requirements here.
14:28:27 <sballe> so I am not willing to say " to accept that the user experience may not be as good as possible "
14:29:04 <mestery> blogan sballe: Can you elaborate on the degregated user epxerience?
14:29:09 <samuelbercovici> if there is an explicit command to provision than you will get the most predicatable user experience
14:29:11 <blogan> sballe: i don't like that either, but is enforcing the load balancer creating last a better user experience?
14:29:23 <sbalukoff> I prefer an implicit provisioning step, because I think this better reflects what will need to happen if certain objects are re-used.
14:29:36 <sbalukoff> For example, if I have a pool that's shared among 5 different listeners...
14:29:44 <sbalukoff> And I update that pool.
14:30:00 <sbalukoff> Should I, as a user, have to go and "provision" all the listeners afterward?
14:30:07 <blogan> mestery: what german said before, in that the user may expect a load balancer if they only do the POST to the /loadbalancers resource, but the load balancer isn't actually there until they link up the listener
14:30:13 <rm_work> ah, true sbalukoff
14:30:19 <sbalukoff> I think it should be implied that the listeners get updated when a pool they depend on gets updated.
14:30:29 <xgerman_> and also we cam throw meaningful error messages
14:30:41 <xgerman_> and not wait for an object the user might not know he has to create
14:31:09 <mestery> blogan xgerman_: That makes sense to me.
14:31:15 <blogan> so in the neutron API, you can't create a subnet or port without first having a network right?
14:31:39 <blogan> so in that case the network was created first, or am I wrong
14:31:45 <rm_work> yeah, order mattering is not a new concept :P
14:31:57 <blogan> im not even sure this analogy is relevant
14:32:02 <mestery> blogan: +1
14:32:17 <rm_work> blogan: that's what you are saying, right?
14:32:48 <blogan> rm_work: yeah but I've also been under the opinion that load balancers API doesn't have to work like neutron's
14:33:04 <blogan> or else we wouldn't be allowing a single create call
14:33:33 <blogan> so basically I'm on the fence on this one, I have no good alternative at this point
14:33:47 <blogan> anyone else have any other alternatives?
14:33:49 <mestery> Lets try to do the right thing from a user experience thing with this API. sballe, what are your thoughts here?
14:34:32 * sballe thinking
14:34:34 <dougwig> it might be useful to consider this in the context of horizon/ui versus cli.  it's possible to do a single create/provision wizard with either scheme in a ui, and for the cli, i'm not sure either behavior is clearly more intuitive than the other.
14:35:35 <dougwig> (i.e. the ui need not directly expose a 'provision' action.  or it could equally as easily fake one, if that was the preference.)
14:35:36 <crc32> I say do it in  single api call but leave provision creation order with LB last internally.
14:35:46 <sballe> mestery, I agree with xgerman_  and blogan  that we definetly need t make sure we have meaningful Warnings and error messages when thngs aren't intiuitive
14:36:07 <ptoohill> I thought it would make sense to be implicit here. So if the user creates all the other sub-objects but no loadbalancer object nothing would be provisioned to the back end. Then if the user attaches these objects to a load balancer the provisioning would happen. This doesnt mean to enforce this order because the user could potentially create only a pool and attach to a load balancer. I think validation should happen here to let them know that
14:36:08 <ptoohill> other 'required' objects are needed before provisioning. Am i thinking about this wrong?
14:36:55 <blogan> ptoohill: in that scenarios what happens when a user creates a load balancer first and nothing else?
14:36:58 <rm_work> hmm that is a point i guess, if the Listener might not be fully populated when attached to the LB, if it tried to provision it would break
14:37:04 <ptoohill> validation?
14:37:21 <mestery> blogan ptoohill: It would fail and generate an appropriate error back?
14:37:32 <ptoohill> I would assume that would be the case
14:37:39 <rm_work> yeah i assume so as well
14:37:44 <blogan> mestery: that is one option, but I believe sbalukoff had objections to enforcing an order
14:37:56 <crc32> blogan:  A fault message telling the user they have an empty loadbalancer is returned
14:38:16 <mestery> sbalukoff: Opinions on this?
14:39:04 <crc32> blogan: Kinda of like what our(Rackspace CLB1.0) API does untill the nodeless loadbalancer feature cruft came out.
14:39:05 <sbalukoff> I'm trying to understand any specific scenario that actually qualifies as a "partially populated" listener, or some other object layout which would be erroneous, and how this differs from just "incomplete"
14:39:24 <blogan> crc32: oh i get how it would work, but that is enforcing a creation order
14:39:36 <sbalukoff> I mean, a load balancer without a listener isn't something that makes sense.
14:39:43 <rm_work> crc32: technically it provisions a working LB according to backend spec :P
14:39:50 <sbalukoff> But a listener without a pool does make sense
14:40:30 <crc32> rm_work: Cruft the way I see it. Synactic sugar at best. :P
14:40:40 <sbalukoff> So, I guess I'm trying to understand what y'all are anticipating as a user's understanding of a layout if it's missing some necessary object to be functional.
14:40:43 <rm_work> yeah, it's cruft… but it's technically correct, which is the best kind of correct
14:40:47 <rm_work> ^_^
14:40:55 <blogan> so another question, it may be a dumb one, but if a load balancer is created last, and a load balancer can have many listeners, how do we specify that relationship on the load balancer call?
14:40:59 <rm_work> anyway, that's off topic
14:41:22 <rm_work> i assumed Listeners would be a list?
14:41:30 <rm_work> or is that not how we wanted to represent it
14:41:33 <sballe> blogan, Why would we not ask the user to create an "empty" LB first and then attach listeners, etc?
14:41:34 <crc32> blogan: with a PUT?
14:42:07 <blogan> sballe: isn't creating an empty LB a bad user experience though?
14:42:13 <ptoohill> not really
14:42:17 <ptoohill> i can see a use case i think
14:42:26 <rm_work> "loadbalancer" { "listeners": [ a, b, c ]  }
14:42:27 <rm_work> no?
14:42:31 <sballe> not if we have the adequate warnings to tell them that more is needed
14:42:39 <rm_work> err,forgot a colon >_>
14:42:47 <crc32> rm_work: Via a PUT right?
14:42:53 <rm_work> PUT or POST
14:42:53 <samuelbercovici> blogan: you can specify a list of listener ids
14:42:57 <ptoohill> If the user wants to spin up just the load balancer object then build his pools, listeners etc then attach to the created load balancer as he goes, is this not acceptable?
14:42:58 <sbalukoff> So I guess, if you're after meaningful error messages, the whole explicit "provisioning" step doesn't make a whole lot of sense to me. If a load balancer layout is incomplete it isn't in error, it's just incomplete.
14:43:09 <rm_work> could be like that in the original POST for the create of the LB, i don't see why noy
14:43:10 <rm_work> *not
14:43:13 <blogan> sam, rm_work: i'm fine with that, I was just throwing that out there
14:43:42 <rm_work> though that then begs, on a PUT to the listeners object, does it do a replace? <_<
14:44:07 <blogan> rm_work: one thing at a time
14:44:14 <rm_work> ah actually sorry, would it be a PUT/DELETE to add/remove via /loadbalancers/<id>/listeners/
14:44:22 <rm_work> lol yeah sorry, getting ahead of things a bit
14:44:32 <blogan> sbalukoff: if create a load balancer is left as the last step, and it is automatically provisioned on that step, would that be fine with you?
14:44:58 <xgerman_> or validated...
14:45:15 <sbalukoff> blogan: No. Because, again, this is a work-flow that doesn't work if you're trying to add a second listener to an existing load balancer
14:45:19 <rm_work> blogan: i think that's full circle to what he didn't like to begin with
14:45:29 <sbalukoff> I want the user to be able to create a loadbalancer object that is not attached to any listener.
14:45:49 <blogan> sbalukoff: i think there will be a add listener call to existing load balancer
14:45:51 <crc32> sbalukoff: I think we need to specify required attributes on our objects and call it an error if those attributes aren't defined in the POST call for the given object. That way we can be sure of what an Error is. Now the question is is a listener a required attribute or not.
14:46:02 <rm_work> crc32: +1
14:46:08 <dougwig> that's implying an order, which i'm not sure is valid for all backends.  if you're doing it all in one go, then pass the entire LB/listener config in one go, and it should be up to the driver to figure out order and return meaningful errors (that's the naive user case, that would be surprised at an incomplete config).   if not, then it's just creating
14:46:08 <dougwig> primitives, and it's up to the user to create them all to hang together properly.  i'm not sure hand holding is as necessary in the second case.
14:46:30 <rm_work> dougwig: also +1
14:46:34 <sbalukoff> dougwig: +1
14:46:40 <mestery> OK, we have 14 minutes left.
14:46:47 <mestery> Is it possible to continue this discussion in the BP blogan has filed?
14:46:53 <sbalukoff> crc32: I would say that 'listener_ids' should not be a required attribute when creating a loadbalancer
14:47:02 <rm_work> blogan / sballe: i think multi-call can be less polished, as it is designed for advanced users anyway? single-call is supposed to be the user-friendly one anyway <_<
14:47:05 <mestery> I wanted to cover at least one of the last two items on the agenda.
14:47:11 <mestery> :)
14:47:13 <samuelbercovici> please note that all calls are a-sync so many errors might be due to the provisioning process itslef
14:47:16 <sbalukoff> mestery: Sure.
14:47:16 <sballe> rm_work, +1
14:47:21 <blogan> mestery: i think that discussion will belong in the second BP that actually implements the API, it might be better to do it on the ML for now until that BP gets put up
14:47:47 <mestery> blogan: Fair point, actually. And that brings up another point, we need someone to write the second BP covering the API as well.
14:47:54 <rm_work> so i am willing to go with sbalukoff's option :P
14:48:15 <sballe> rm_work, please summarize that option
14:48:29 <rm_work> sballe: we'll do it on the ML it looks like
14:48:30 <crc32> dougwig: The public facing API should have required attributes and optional attributes. I think pushing that off to the driver is a bad idea.
14:48:37 <mestery> rm_work: MAybe a quick summary here?
14:48:41 <blogan> mestery: obviously I or someone at rackspace can do it, but if someone wants to get in on the process by all means go for it
14:48:53 <mestery> Thanks blogan!
14:48:54 <crc32> or rather pushing off to the driver to define whats required or not is a bad idea.
14:49:05 <rm_work> by sbalukoff's option, i just meant "order doesn't matter, and LB can be created by itself".
14:49:14 <mestery> rm_work: That's a good summary. :)
14:49:29 <samuelbercovici> which I also like
14:49:30 <sballe> rm_work, +1 I like sbalukoff option too ;-)
14:49:42 <dougwig> crc32: agreed.  it's just order that's problematic to hardcode, and that can be gotten around by thinking of it as two modes.
14:49:42 <mestery> Yay! I think we're all in agreement on that one?
14:49:45 <rm_work> since what we really care about for "user experience" is single call, and it won't have these problems :)
14:49:50 <rm_work> and will have it's own validation
14:50:02 <sballe> agreed
14:50:06 <sbalukoff> Yep.
14:50:14 <blogan> awesome we have consensus!
14:50:52 <mestery> OK, moving on for the last 10 minutes.
14:51:00 <dougwig> which of the last two topics is more contentious?  (the statement that all we need to change in the driver is renaming vip is dead wrong, but i can take that to the bp review if we run out of time.)
14:51:25 <mestery> dougwig: I think the last one, though the subnet_id one was also contentious.
14:51:39 <mestery> LEts take the subnet_id one to the BP maybe.
14:51:41 <blogan> dougwig: please do I didn't give a lot of thought to it so maybe it should go in the ML because I'm not sure when that 2nd BP will be up
14:51:44 <mestery> I think it makes sense for folks to comment there.
14:51:49 <dougwig> the subnet one took a lot of time at the summit.
14:51:54 <mestery> dougwig: Yes. :)
14:52:03 <mestery> Do people want to flesh taht out here for 9 minutes?
14:52:26 <blogan> mestery: the subnet_id location?
14:52:40 <mestery> blogan: Yes, per the agenda.
14:52:57 <sbalukoff> subnet_id should be an attribute of the member.  Done. ;)
14:53:00 <rm_work> summarizing options: subnet_id per poolMember, subnet_id per pool, subnet_id_list on LB?
14:53:00 <blogan> well to me I've come around on the idea that the subnet_id should be on the pool member, but I obviously am not set in stone on this
14:53:04 <mestery> sbalukoff: :P
14:53:05 <crc32> blogan: I'm on my way in now but I'm talking with sam about some SSL terminology when I get in too so we can work on the BP after that.
14:53:12 <rm_work> i am for subnet_id on pool member
14:53:36 <blogan> crc32: okay, unless someone else in this room not from rackspace wants to get in on the process
14:53:38 <samuelbercovici> i am for subnet_id on lb
14:53:51 <crc32> oh ok sorry.
14:54:09 <blogan> samuelbercovici: do you have strong issues against it being on the pool member?
14:54:18 <crc32> heading out now. ETA 20 minutes
14:54:31 <samuelbercovici> yes
14:54:34 <sbalukoff> samuelbercovici: I think your concerns about this have to do with the idea that when provisining an appliance in nova, there isn't a way to add a new neutron_port to it afterward, right?
14:54:39 <rm_work> enumerate your issues?
14:54:57 <sbalukoff> Yes, sorry-- don't mean to put words in your mouth.
14:55:02 <samuelbercovici> sbalukoff: not only this
14:55:20 <rm_work> sbalukoff: is that a limitation? I know there is a way to get around that in Rackspace's implementation, but i guess maybe not in stock Neutron/Nova?
14:55:34 <s3wong> sbalukoff: I think we are definitely trying to fix that in ServiceVM
14:55:35 <samuelbercovici> pool is a logical constructs of ser of memebers
14:56:11 <sbalukoff> s3wong: That's good to hear!
14:56:18 <samuelbercovici> so you should be able to specify memebrs that reside on deifferent subnets
14:56:39 <sballe> s3wong, any ETA for when this will be fixed?
14:56:44 <blogan> samuelbercovici: puttin the subnet_id on the pool member allows this
14:56:49 <sbalukoff> samuelbercovici: True, but you can do this if subnet_id is an attribute of Member.
14:57:07 <rm_work> i thought that was *specifically* why we wanted it on poolMembers :P
14:57:24 <samuelbercovici> sbalukoff: correct but then you need to do this for all memebrs
14:57:34 <sbalukoff> Yes. Yes you do.
14:57:42 <sbalukoff> Well...
14:57:43 <samuelbercovici> the canonical place is the lb
14:57:48 <sbalukoff> Ok, so actually no...
14:57:52 <rm_work> so the objection is that if all members are on the same subnet, it is a lot of redundancy?
14:57:53 <s3wong> sballe: well, TBH, us in ServiceVM team is still trying to come up with a list of requirements on what makes ServiceVM different from regular VM, and will file bps accordingly
14:58:03 <sbalukoff> My thought was that you could have subnet_id be an optional attribute of the member.
14:58:09 <vivek-eb_> members in different network is a important requirement for us at ebay too
14:58:18 <samuelbercovici> also if you use multiple pools for l7, there is redundency there
14:58:24 <sbalukoff> Having a specified subnet_id implies that the loadbalancer appliance needs layer-2 connectivity to that subnet to talk to the given member.
14:58:30 <sbalukoff> Which won't be the case if the member is routed.
14:58:49 <rm_work> sbalukoff: though if it's optional, and we DO compile a list of subnets dynamically to use for the LB, and the user puts NO subnets… it might be non-intuitive that it doesn't work? dunno
14:59:08 <mestery> OK, we have < 2 minutes left now.
14:59:14 <mestery> I propose we take this subnet discussion to the BP and/or ML.
14:59:17 <sbalukoff> rm_work: No subnets specified means that all members are routed. :)
14:59:19 <rm_work> yeah, probably ML
14:59:27 <mestery> The focus this week is reviewing the BP from blogan.
14:59:29 <rm_work> sbalukoff: theoretically :P but maybe not? :P
14:59:29 <sbalukoff> Yeah, ML makes sense
14:59:35 <mestery> Lets all make sure we do that before the meeting next week.
14:59:45 <xgerman_> mestery +1
14:59:47 <mestery> Thanks for attending this week everyone!
14:59:55 <xgerman_> thanks
14:59:59 <s3wong> thanks
15:00:02 <sballe> bye
15:00:04 <mestery> One last thing: I should be sending out notes on the LBaaS mid-cycle today.
15:00:06 <sballe> and thanks
15:00:07 <mestery> Look for that on the ML.
15:00:12 <mestery> #endmeeting