14:03:18 <enikanorov> #startmeeting neutron lbaas
14:03:19 <openstack> Meeting started Thu May  8 14:03:18 2014 UTC and is due to finish in 60 minutes.  The chair is enikanorov. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:23 <openstack> The meeting name has been set to 'neutron_lbaas'
14:03:44 <ctracey> morning
14:03:59 <samuelbercovici> hi
14:04:04 <enikanorov> I'd like to propose 2 topics for todays meeting
14:04:13 <enikanorov> 1. agenda for design tracks
14:04:20 <enikanorov> 2. comparison of API proposals
14:04:27 <enikanorov> in that order
14:04:32 <TrevorV> morning!
14:04:33 <mestery> +1 to that enikanorov
14:04:37 <rm_work> sounds good to me
14:04:39 <aburaschi> +1
14:04:41 <samuelbercovici> +1
14:04:43 <rm_work> err, +1
14:04:45 <sbalukoff> Ok!
14:04:48 <enikanorov> i suggest that (2) is going to take more than 1 meeting, so lets start with what is more important right now
14:04:50 <german_> +1
14:05:00 <ctracey> +1
14:05:04 <edhall> +1
14:05:05 <rm_work> yes, (2) will probably extend into the summit
14:05:57 <enikanorov> so, as I said in email, design tracks are not a place for in-depth discussion, so we need to come up with a list of items that require core team attention
14:06:30 <enikanorov> right now a have two questions in mind
14:06:36 <enikanorov> s/a/I
14:06:50 <enikanorov> the first one is a policy of integration with barbican
14:07:12 <mestery> enikanorov: That one is an important session for not only LBaaS, but also VPNaaS.
14:07:29 <samuelbercovici> mestery:+1
14:07:31 <enikanorov> mestery: are you suggesting to move it to different design track?
14:07:45 <enikanorov> *design session
14:07:51 <mestery> enikanorov: Nope, I'm just saying the VPN folks will be very interested to partake in that discussion
14:08:00 <rm_work> I have friends on the barbican team, can make sure there is some representation from them at our track so they can answer questions we might have
14:08:02 <enikanorov> ah, sure
14:08:23 <german_> I finally found the barbican people inside HP...
14:08:33 <enikanorov> that's good to know
14:08:37 <sbalukoff> Heh!
14:08:56 <rm_work> german_: I found the barbican people inside RS too, they sit within nerf dart range of me :P
14:08:56 <enikanorov> so, whole SSL support then splits into 2 questions IMO:
14:09:11 <mestery> rm_work: That woudl be great!
14:09:14 <rm_work> german_: I guess HP might be bigger :)
14:09:14 <enikanorov> 1) will it be ok to write DB driver for cert storage (with proper documentation)
14:09:30 <german_> rm_work plane ride away :-)
14:09:30 <enikanorov> 2) will it be ok to rely on barbican (considering it's not an integrated project yet)
14:09:52 <mestery> IMHO, we as a larger team may need to commit resources to barbican to help with #2.
14:10:01 <samuelbercovici> also where is the canonical API resides to store and consume SSL certificates?
14:10:03 <sballe_> enikanorov, Our security lead seems to think that for production Barbican is not ready yet
14:10:03 <sbalukoff> Well, I know how I come down on those questions. :)
14:10:04 <mestery> It's something we should figure out next week, as making it core will be important.
14:10:37 <enikanorov> mestery: i see
14:10:44 <enikanorov> btw, i forgot to mention
14:10:47 <enikanorov> #link https://etherpad.openstack.org/p/juno-neutron-lbaas
14:10:49 <sballe_> but longer term Barbican is the rigth approach
14:11:05 <german_> yeah, we need to compare road maps
14:11:11 <enikanorov> i suggest to write your proposed discussion items there
14:11:41 <rm_work> sballe_: we brought up your exact concern with the barbican guys here and they seem to think there's work to be done but nothing that would be a showstopper for our timeline
14:11:57 <sballe_> rm_work, good to know. thanks
14:12:00 <mestery> rm_work: That's good to know!
14:12:16 <german_> +1
14:12:23 <enikanorov> ok, the next big question which i think worth discussing with a core team is 'networking function vs virtualized appliance'
14:12:32 <sballe_> so let's assume barbican will be ready when we need it to be
14:12:37 <enikanorov> as it a core question for our 'loadbalancer resource' discussion
14:13:04 <TrevorV> I have already spoken to one of the guys on the Barbican team here at Rackspace; he said they'll have someone at our discussions during the summit
14:13:21 <rm_work> Hopefully John Wood and Paul Kehrer can make it
14:13:27 <sbalukoff> enikanorov: Can you expand on that idea a bit? I'm not sure what you mean by "networking function vs. virtualized appliance"
14:13:38 <rm_work> I think they're the tech lead and cryptography guy
14:13:40 <sballe_> enikanorov, I agree if I am understanding your point right. Networking fucntions is core the Neutron, virtualized appliance is LBaaS or other advanced service?
14:14:14 <enikanorov> sbalukoff: i'd like to, but so far that was a quite blurry explanation of why we don't want to provide 'logical loadbalancer appliance' functionality
14:14:26 <enikanorov> limiting it with particular objects like vips/pools/etc
14:14:32 <sbalukoff> Whose explanation?
14:14:34 <TrevorV> rm_work: John is who I spoke with
14:14:48 <enikanorov> sbalukoff: Mark McClain's, for instance
14:14:51 <rm_work> TrevorV: excellent :)
14:15:10 <sbalukoff> Right. I guess it's important to know, does mestery feel the same way?
14:15:13 <enikanorov> sbalukoff: i think it's some project-wise design consideration that needs to be clearly explained
14:15:34 <sbalukoff> enikanorov: I agree!
14:15:42 <enikanorov> so far i could not fully understand the reason behind it
14:15:47 <german_> is this something we can do on the mailing list - or is that summit?
14:15:53 <sballe_> enikanorov, I feel we have been down this road before and most people in the group feel that we need a loadbalancer thing and not a bucnh of pieces that a user can bundle together
14:16:05 <sbalukoff> I would *love* for someone there to quantify why they think the virtual appliance model violates concerns around "implementation details". :)
14:16:13 <rm_work> german_: I am thinking the high-bandwidth of the summit might help a lot with this
14:16:16 <mestery> This will be ML and Summit discussion I suspect, which is why enikanorov brought it up here.
14:16:22 <rm_work> I can't seem to get my point across well in text, I think
14:16:29 <samuelbercovici> enikanorov: the reason was that if the reason to use load balancer is for scheduling then there is different scemantics to use
14:16:50 <enikanorov> samuelbercovici: please explain?
14:17:02 <salv-orlando> a LoadBalancer instance, being represented as an object which can contain a collection of VIPs and other resources, probably did not seem a great construct from the user perspective. It surely did not made their life easier. Even if the counter argument is that It probably recalled how 'real' load balancers are structured.
14:17:26 <samuelbercovici> looking at the use cases they needed loadbalncer as a way to specify affinity and and anti-affinity
14:17:38 <salv-orlando> real has been quoted because it might refer to both phisical and virtual appliances
14:17:44 <jorgem> salv-orlando: our customers (users) beg to differ
14:17:44 <enikanorov> salv-orlando: thanks
14:17:46 <samuelbercovici> this is better represented IMO in the way nove does it with insatnce groups
14:17:55 <rm_work> salv-orlando: I am curious if maybe we have different definitions of who a "user" is
14:18:06 <enikanorov> so to me i goes down to a question, if a single logical loadbalancer needs more then one L2 port
14:18:09 <ctracey> jorgem: as do the thousands of elb users
14:18:14 <rm_work> which could explain some of the confusion
14:18:14 <blogan> salv-orlando: why do you think it does not seem a great construct from the user perspective?
14:18:17 <sbalukoff> salv-orlando: Our customers also beg to differ. :)
14:18:51 <salv-orlando> I have been pointing out what came out from a discussion of a proposed API change in the Juno life cycle.
14:18:59 <salv-orlando> Sorry Icehouse
14:19:09 <blogan> salv-orlando: ah so is it not your opinion?
14:19:12 <salv-orlando> or was it probably Havana? It does not matter anyway.
14:19:14 <sbalukoff> Got it. Time to revisit that discussion. :)
14:19:27 <enikanorov> salv-orlando: yeah, it's a long story
14:19:31 <salv-orlando> In my opinion the problem is not a "load balancer" instance.
14:19:53 <german_> let's table that for the (2) agenda iteam?
14:20:04 <sbalukoff> german_: +1
14:20:07 <blogan> german_: agreed
14:20:09 <rm_work> I almost want to table this until Monday <_<
14:20:11 <mestery> Yes
14:20:22 <salv-orlando> My opinion is that I don't think a good API is an API that pretty much is a RESTification of the backend API many appliances offer
14:20:36 <german_> +1
14:20:37 <edhall> salv-orlando, agreed
14:20:42 <mestery> +1 salv-orlando
14:20:44 <rm_work> +1
14:20:51 <sballe_> +1 for Monday
14:21:22 <mestery> I think this discussion is something to talk about next week. We should add this to the etherpad.
14:21:24 <sbalukoff> salv-orlando: I'd love to hear more of your opinion on this. But it can wait until Monday, eh. :)
14:21:31 <samuelbercovici> +1 salv-orlando
14:21:36 <enikanorov> and what is for multiple L2 ports per logical loadbalancer?
14:21:47 <ctracey> +1 sbalukoff
14:22:03 <enikanorov> do we need more than one neutron port per LB?
14:22:05 <samuelbercovici> enikanorov: please explain
14:22:08 <salv-orlando> enikanorov: I've not been following enough load balancing to understand what you mean here
14:22:26 <german_> I think so
14:22:31 <enikanorov> sorry, i meant do we need multiple VIPs per sinlge logical balancer
14:22:41 <german_> yes, we do
14:22:45 <enikanorov> i mean that each VIP has its own neutron port and IP
14:22:53 <german_> a load balancer might be present in multiple subnets
14:22:56 <sballe_> I agree with german_ We do
14:22:58 <samuelbercovici> enikanorov: what is the use case that requires this?
14:23:03 <sbalukoff> enikanorov: Given some of the use cases, we might. Though it's probably worth a more in-depth discussion of the implications of more than 1 neutron port per logical LB
14:23:05 <enikanorov> german_: no, that's not the case
14:23:14 <enikanorov> samuelbercovici: i didn't see any, that's why i'm asking
14:23:31 <enikanorov> german_: 1 neutron port can be on multiple subnets also
14:23:39 <sballe_> enikanorov, can you clarify "that is not the use case"?
14:23:40 <enikanorov> german_: we don't need multiple VIPs to handle that
14:23:48 <samuelbercovici> enikanorov: the ones I have seen in the tenant facing use cases were for scheduling purposes
14:24:12 <vivek-ebay> IP:80 for HTTP, SAME_IP:443 for HTTPS. does what use-case fit here ?
14:24:15 <sbalukoff> enikanorov: Introducing the restriction that a logical load balancer must exist on only one neutron port might make sense--  I'd love to hear / see discussion as to why it does or doesn't.
14:24:30 <enikanorov> vivek-ebay: that is handled by 1 VIP+multiple listeners model
14:24:36 <enikanorov> vivek-ebay: not multiple VIPs
14:25:09 <enikanorov> sbalukoff: I think it's fair limitation. If we go beyong it, we put user in much control of a backend
14:25:33 <TrevorV> enikanorov: what about ipv4 and ipv6?
14:25:39 <ctracey> +1 enikanorov
14:25:39 <mestery> Folks, I'd like to point out we're wandering a bit here off the agenda proposed at the start of the meeting.
14:25:41 <enikanorov> TrevorV: that's multiple subnets
14:25:50 <enikanorov> TrevorV: still single neutron port and hence 1 VIP
14:25:54 <mestery> We're 25 minutes in and we need to focus on items to discuss F2F next week.
14:26:02 <jorgem> mestery: indeed
14:26:04 <enikanorov> mestery: true
14:26:06 <german_> +1
14:26:08 <sbalukoff> mestery: +1
14:26:14 <samuelbercovici> mestery: +1
14:26:14 <mestery> Can people update the etherpad here with those ideas? https://etherpad.openstack.org/p/juno-neutron-lbaas
14:26:20 <sbalukoff> enikanorov: Let's discuss via ML
14:26:24 <mestery> enikanorov linked it earlier. :)
14:26:41 <sballe_> I am assuming the APIs should be a item on the summit agenda
14:26:55 <samuelbercovici> sballe_:+1
14:26:57 <german_> +1
14:27:06 <enikanorov> sballe_: we hardly will be able to discuss it on design session
14:27:21 <enikanorov> i don't think it makes sense to cover it...
14:27:34 <enikanorov> design session is even shorter than our weekly meeting
14:27:35 <blogan> mestery: what is the current topic?
14:27:48 <mestery> blogan: Summit ideas for next week to discuss F2F
14:27:50 <enikanorov> blogan: agenda for design sessions
14:28:06 <sballe_> enikanorov, The problem is we need to get agreement around the APIs otherwise we are going nowhere and we know from the past that it is hard to discuss it on IRC
14:28:25 <samuelbercovici> When do we want to review the survey results?
14:28:28 <enikanorov> sballe_: that is something we do offline, but not on the design session
14:28:36 <mestery> sballe_: The second part of this meeting was around the API comparison.
14:28:40 <ctracey> Does it make sense to grab a spare meeting room for a breakout session? I have done this with other projects and it had been quite useful.
14:28:40 <rm_work> enikanorov / sballe_: we should probably have open discussions about it prior to official sessions, and TRY to use the official sessions to agree officially on a direction?
14:28:43 <mestery> sballe_: If we're done with summit ideas, we can move there.
14:29:02 <jorgem> After API, how about HA and SSL Term since the requirements point towards that being top priority?
14:29:07 <sballe_> rm_work, +1
14:29:14 <german_> jorgem +1
14:29:25 <sbalukoff> jorgem: +1
14:29:32 <enikanorov> jorgem: please write it on the etherpad then
14:29:45 <german_> also I am still new and would like to learn more about the dev process / and how to divvy up work
14:29:47 <samuelbercovici> I would like to present SSL and L7 in light of what was done and the proposals
14:30:06 <samuelbercovici> 2nd session could be used for this
14:30:08 <sballe_> german_, +1 same here
14:30:40 <jorgem> enikanorov: complete
14:30:51 <mestery> For the dev process, we will need BPs approved for all the LBaaS work before any changes will be accepted into Juno.
14:30:54 <enikanorov> ok, on slightly different matter
14:30:59 <mestery> We should ideally ahve those in review the week after the summit.
14:31:13 <enikanorov> i'll be able to host a meeting at mirantis room some time on wednesday
14:31:14 <blogan> mestery: is it first a neutron-spec BP, then a neutron BP, then do the work?
14:31:22 <german_> +
14:31:24 <enikanorov> what time will be most appripriate for you foklks?
14:31:43 <sballe_> I am going to add API to the list with the caveat taht is is more around as rm_work said "agreeing on a direction"
14:31:44 <mestery> blogan: A BP in neutron-specs, which is linked from the LP BP. The LP BP is only used to track progress against milestones.
14:31:59 <blogan> mestery: thanks that clears it up for me
14:32:17 <jorgem> sballe: Corret, hopefully we can do that today since that is what was suggested last week.
14:32:29 <mestery> jorgem: Yes!
14:32:45 <mestery> Should we move to API comparison now?
14:32:49 <rm_work> jorgem: agreeing on a direction? :P
14:32:54 <TrevorV> +1 mestery
14:33:04 <mestery> I think we have enough ideas for next week to discuss in person now as I look at the etherpad.
14:33:07 <rm_work> I think that might be a longshot for the next 27 minutes T_T
14:33:08 <jorgem> rm_work: for the API. There are only two proposals. So let's pick one
14:33:20 <sballe_> jorgem, I can delete the item from the tehrpad if we close it today
14:33:27 <rm_work> jorgem: as I said in my email, I really don't think that should be the goal
14:33:29 <jorgem> sballe: Sounds good to me
14:33:31 <mestery> jorgem: The idea was to find gaps as the proposals were close, correct?
14:33:49 <jorgem> mestery: Yes I believe so.
14:33:52 <rm_work> "I'd like to assume that what we're really discussing is making a third revision of the proposal, rather than whether to use one or the other verbatim."
14:34:05 <blogan> mestery: i spoke to sbalukoff about making a change to his API that I think we, as Rackspace, can get behind
14:34:15 <blogan> mestery: I believe stephen said he is on board with this
14:34:15 <jorgem> rm_work: We are trying to find a foundation. It isn't set in stone verbatim.
14:34:23 <sbalukoff> blogan: Yep, I am!
14:34:50 <blogan> mestery: this will hopefully speed that process up of choosing an API
14:34:56 <mestery> So, have we reached a consensus then between the two proposals due to the discussions blogan and sbalukoff have had?
14:35:10 <sbalukoff> rm_work: I also agree that whatever we end up with will not be exactly (verbatim) like either of our existing proposals.
14:35:18 <jorgem> mestery: Perhaps, but I think they should explain the changes.
14:36:05 <jorgem> sbalukoff: Correct, even though a lot of time and thought have been put into the proposals I still think we will inadvertently miss some small things.
14:36:18 <blogan> so really the only change is load balancer is the top level object, but it has an array of VIPs, and each VIP has an array of Listeners
14:36:38 <german_> sounds good :-)
14:36:40 <sbalukoff> So, this is somewhat a return to the "virtual appliance" model.
14:37:00 <enikanorov> sbalukoff: yes, that's something a core team is not accepting
14:37:04 <sbalukoff> That I think a *lot* of people here like, and are waiting to hear why we can't do this. XD
14:37:16 <jorgem> and stuff like colocation goes on the lb object correct?
14:37:18 <sballe_> sbalukoff, +1
14:37:23 <blogan> jorgem: yes
14:37:24 <rm_work> I am curious if, upon reviewing the Rackspace CLB API, and the Amazon ELB API, the same people who disagree with using the term LB here would argue for those APIs to change their terminology too <_<
14:37:45 <sbalukoff> blogan +1
14:37:54 <enikanorov> rm_work: it's not about the term
14:38:02 <rm_work> enikanorov: it seems to be
14:38:09 <enikanorov> rm_work: it's about the API construct
14:38:27 <blogan> enikanorov: can you give more details about what is not liked about the construct?
14:38:35 <rm_work> the only real opposition I keep hearing is that it doesn't "correctly give an impression of what is contained" or something like that
14:39:01 <rm_work> like "it only contains one L2 thing and not multiple, so it's not really a LB", etc
14:39:01 <enikanorov> blogan: i can only refer to a salv-orlando opinion, and also i don't see a reason to have more than 1 l2 port per loadbalancer
14:39:21 <rm_work> (I am quoting badly but i don't have time to look up the exact text right now, since this moves so quickly, sorry)
14:39:38 <sballe_> we are now back in this circle that we haven't been able ot get out off since we started discussing this
14:39:51 <blogan> enikanorov: the API doesn't define how many L2 ports are actually created
14:39:52 <german_> +1
14:40:22 <sballe_> +1
14:40:22 <enikanorov> blogan: i mean l2 ports for the front end
14:40:26 <sbalukoff> Regardless of the name of the thing (I'm not strongly either way on this-- and y'all have heard my opinion in detail on the mailing list), I think it's more about the logical construct of the virtual appliance in the model.
14:41:21 <mestery> sbalukoff: The API is defining the construction of the virtual appliance? Not following this.
14:41:25 <ctracey> +1 sbalukoff
14:41:39 * rm_work starts looking up the ascii-art for flipping a table
14:41:40 <sbalukoff> enikanorov: I would like to see ML discussion from you as to why you think we should introduce the restriction that a load balancer construct should only have one L2 port on the front end.
14:42:30 <enikanorov> sbalukoff: i'd better ask why we want more then one
14:42:55 <sbalukoff> mestery: Yes. So essentially, when a user interacts with the "load balancer as a service" the thing they get is an abstracted logical load balancer (which can contain VIPs, Listeners, Pools, etc.)
14:42:55 <aburaschi> Where would the right doc to look to better understand the NVF vs Virtual Appliance approaches we're discussing?
14:43:09 <sbalukoff> mestery: It makes the colocation / apolocation problem a lot easier.
14:43:21 <samuelbercovici> sbalukoff: besides scheduling VIPs in the same place or on different places, what is the reason to have loadbalancer as an object that can contain multiple vips?
14:43:30 <sbalukoff> And it gives us a thing we can use to answer operator concerns later on.
14:44:00 <sbalukoff> samuelbercovici: From the user's perspective, that is the reason!
14:44:02 <blogan> enikanorov: if a user defines multiple VIPs in the API why can't that all go into one L2 Port?
14:44:13 <enikanorov> sbalukoff: but that problem has other solutions rather than putting it on user's shoulders
14:44:26 <sbalukoff> But I think as we further discuss operator concerns, operators will have more reasons to have this construct.
14:44:29 <enikanorov> blogan: multiple listeners you mean
14:44:39 <salv-orlando> I want to throw a bit more chaos… and that's about harmony across all areas of the APIs. I have a feeling that this moves in the opposite direction wrt activities such as policies-oriented APIs are moving.
14:44:42 <samuelbercovici> sbalukoff: than we can use policies for placement similar to nova
14:44:52 <sbalukoff> enikanorov: They might be able to.
14:44:55 <salv-orlando> or am I reading it wrong?
14:44:58 <enikanorov> samuelbercovici: +1
14:45:00 <samuelbercovici> you don's see a root object called hypervisor in nova
14:45:11 <enikanorov> salv-orlando: correct
14:45:14 <TrevorV> enikanorov: You've stated many times multiple ips on a single neutron port, but looking into the Neutron Port documentation, it defines one subnet for these multiple ports.  This apparently negates the concept of an IPv4 and an IPv6 on the same Neutron Port, does it not?
14:45:22 <sbalukoff> samuelbercovici: But you do see a virtual server.
14:45:25 <rm_work> samuelbercovici: you do see a "server", which is equivilent to what we're talking about here
14:45:32 <TrevorV> sorry, one subnet for multiple IPs
14:45:38 <enikanorov> TrevorV: nope, look at fixed ips that port may have
14:45:57 <enikanorov> TrevorV: we can discuss that after the meeting
14:46:02 <mestery> sbalukoff: So are you saying the Open Source implementation of these new APIs will be a virtual appliance? I'm fine if the API allows for appliances as implementations (see VPNaaS), but I'm concerned if the open source default verison is an appliance.
14:46:06 <samuelbercovici> not sure I understand
14:46:19 <sbalukoff> mestery: No!
14:46:23 <sbalukoff> I'm not saying that!
14:46:40 <sbalukoff> I'm staying there is a lot of flexibility in how you actually implement the "load balancer construct" for the user.
14:46:44 <sbalukoff> Virtual appliance is one way.
14:46:47 <enikanorov> sbalukoff: rm_work: virtual server is not an equivalent
14:46:48 <samuelbercovici> a vip in the way sbalukoff defined is the biggest construct I will ever be interested as a user
14:46:50 <sbalukoff> An array of virtual appliances is another.
14:46:57 <enikanorov> samuelbercovici is right about hypervisor
14:46:58 <sbalukoff> haproxy on the neutron controller is another.
14:47:06 <mestery> sbalukoff: OK, just wanted to make sure. :)
14:47:24 <rm_work> samuelbercovici: you are not an average user, apparently <_<
14:47:37 <sbalukoff> samuelbercovici: Our users often care about colocation / apolocation (or affininty / anti-affinity)
14:47:38 <samuelbercovici> I might wish to place some shceuling information such as affinity and falvor to assist in how it gets provisioned
14:48:13 <enikanorov> samuelbercovici: right, flavors are better in addressing that
14:48:20 <sballe_> sbalukoff, +1
14:48:38 <german_> scheduling is another nig issue
14:48:40 <sbalukoff> flavors still have a place here.
14:48:49 <german_> absolutely
14:48:51 <samuelbercovici> sbalukoff: why is this requirement different than https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension
14:49:17 <rm_work> maybe all of the tens of thousands of users of CLB / ELB are the weird ones, expecting to actually deal with a "loadbalancer" when they use a load balancing service? <_<
14:49:25 <sbalukoff> samuelbercovici: I will have to read through that blueprint before I can answer that.
14:49:43 <rm_work> </sarcasm>
14:49:49 <sbalukoff> rm_work: Haha!
14:49:52 <sballe_> rm_work, Our users deal with LB also in our LBaaS service. :-)
14:49:55 <enikanorov> rm_work: that's about the term. elb API is very limited
14:50:03 <samuelbercovici> also the ELB loadbalancer as far as iknow == sbalukoff:vip
14:50:12 <enikanorov> samuelbercovici: correct
14:50:12 <rm_work> sballe_: erk, sorry to exclude you :P i don't know your acronum
14:50:14 <blogan> i don't think the term LB is at issue here
14:50:14 <rm_work> *acronym
14:50:22 <blogan> its the multiple VIPs
14:50:26 <blogan> am i wrong here?
14:50:28 <samuelbercovici> which is different than the Rackspace definition of loadbalancer
14:50:31 <enikanorov> blogan: it's multiple listeners
14:50:59 <blogan> enikanorov: then i am confused
14:51:14 <sbalukoff> I sort of started discussion of what "load balancer" should mean on the mailing list.
14:51:18 <blogan> enikanorov: listener representing a TCP/UDP port?
14:51:22 <sbalukoff> I doubt we're going to come to consensus in this IRC meeting.
14:51:27 <sbalukoff> Maybe people use use ML discussion?
14:51:28 <samuelbercovici> well, can we do this at the confference F2F, this will be real usefull to be able to also draw stuff
14:51:29 <enikanorov> blogan: tcp/upd port/protocol/ssl
14:51:56 <enikanorov> blogan: no multiple IP per loadbalancer in ELB
14:52:16 <blogan> enikanorov: what does ELB have to do with it?
14:52:22 <german_> +1
14:52:31 <sbalukoff> Just to revisit this, though: The idea of having a "logical construct load balanacer virtual appliance thingy" is central to the compromise blogan and I were talking about.
14:52:40 <sballe_> samuelbercovici, +1. We have tried to this on the IRC and on the ML and never really got consensus. A face to face meetign will help to get this discussed and nailed down
14:52:40 <samuelbercovici> blogan: weel ELB was used to reflect the use of the term loadbalncer
14:52:41 <aburaschi> Is this something we could summarize in a pros/cons list? (the appliance/nfv thing)...
14:52:44 <sbalukoff> Between our API proposals.
14:53:03 <rm_work> it appears that they return a call-named structure, containing just a DNS name, but the term LoadBalancer is stamped ALL over their docs
14:53:15 <samuelbercovici> so when can everyone interested meet if not on LBaaS session?
14:53:17 <rm_work> nothing about a VIP
14:53:32 <enikanorov> i'm proposing to have a meeting on wednesday
14:53:36 <enikanorov> in mirantis private room
14:53:44 <jorgem> mestery: Can we identify the issues with compromised API proposal?
14:53:48 <enikanorov> i need to coordinate with my team to find out the time
14:53:59 <ptoohill> I know this is a bit off of which ever topic is being discussed at the moment. But how do these talks fit in if ejecting advanced services is still up for discussions. Should i not be worrying about that at this point?
14:54:00 <mestery> jorgem: Yes, that was the idea. We have 7 minutes. :)
14:54:03 <blogan> can we get a detailed description of the objections to this on the ML? I'd really like to understand it so I can make an informed decision, I'm definitely missing something
14:54:03 <rm_work> I'm proposing we have a meeting Monday and Tuesday and Wednesday and continue until we actually decide something we agree on <_<
14:54:10 <sballe_> enikanorov, sounds good. The Neutron pod migth be available too
14:54:22 <mestery> rm_work: Should we start on Sunday perhaps?
14:54:27 <sbalukoff> Heh! I haven't nailed down everything on my summit agenda yet. enikanorov: Can you send out info on this to the mailing list?
14:54:31 * mestery runs and hides. :)
14:54:34 <rm_work> mestery: if you all want to meet for a beer, I get in sunday night :P
14:54:37 <sballe_> mestery, Unfortunately I will first be there Monday
14:54:44 <sbalukoff> mestery: I could do Sunday evening.
14:54:49 <sbalukoff> Dang.
14:54:50 <rm_work> mestery: point us to a good pub :)
14:54:51 <enikanorov> sbalukoff: sure
14:55:01 * mestery takes note to find a place for Sunday evening.
14:55:02 <enikanorov> i think that will be personal invites
14:55:13 <german_> I get there Monday as well
14:55:23 <german_> not very interested in keynotes :-)
14:55:30 <blogan> enikanorov: can you send an email on the ML with a detailed objection to multiple listeners?
14:55:32 <mestery> german_: :P
14:55:46 <blogan> enikanorov: speak to me like im a child, i dont care, i just want to understand it
14:55:48 <samuelbercovici> blogan: no one objects to multiple listeners
14:55:53 <sballe_> I am just two hours away so I should be in Atlanta aaround 9am on Monday
14:55:56 <enikanorov> blogan: i have no objection on multiple listeners, as they are descried in BBG API proposal
14:56:04 <sbalukoff> Oh! Can we get everyone to please fill out samuel's survey before the summit?
14:56:13 <blogan> enikanorov: then what ever the object you have is
14:56:19 <samuelbercovici> blogan: the objections is to multiple different IPs (for VIPs) under a loadbalancer object
14:56:23 <sbalukoff> And samuel: Can you share the preliminary data from the survey?
14:56:31 <blogan> enikanorov: and i realize it is not just you, but you understand the general objection
14:56:34 <sbalukoff> (at the summit)
14:56:52 <samuelbercovici> esurv.org/online-survey.php?surveyID=OBDJOJ_e56c2e0b&u=lbaas_project_user
14:56:56 <enikanorov> blogan: yes, samuelbercovici is correct about what people (including me) object  to
14:56:59 <samuelbercovici> password lbaas
14:57:15 <blogan> samuelbercovici: is the object just because not all load balancing implementations allow multipel VIPs?
14:57:31 <sbalukoff> enikanorov: I would love to see mailing list discussion about multiple l2 ports on a load balancer object.
14:57:35 <rm_work> samuelbercovici / sbalukoff: my survey answers would probably be verbatim what jorge put down, but I guess I can do it anyway if we'll be compiling metrics based on overall responses <_<
14:57:42 <enikanorov> sbalukoff: ok sure
14:58:06 <sbalukoff> rm_work: It's not anonymous, so it doesn't hurt to have many people from the same organization filling out the survey.
14:58:10 <aburaschi> wow, quite a complete survey :)
14:58:10 <samuelbercovici> blogan: noin my opinion it violates the freedome of the backend to properly and efficiently scheule
14:58:30 * mestery notes there is only 2 minutes left in the meeting.
14:58:33 <sbalukoff> aburaschi: Yes! Please fill it out. :D
14:58:47 <samuelbercovici> blogan:if the reason is for affinity, than it should have the right "hints" to say so and not using an hierarhical cunstruct
14:58:55 <mestery> Lets use the etherpad enikanorov posted for discussions next week during the LBaaS sessions.
14:58:58 <sbalukoff> Ok, anything left unresolved about the meeting agenda for next week should happen on the mailing list.
14:59:10 <mestery> Agreed sbalukoff.
14:59:12 <sbalukoff> Or etherpad.
14:59:13 <sbalukoff> :)
14:59:15 <blogan> samuelbercovici: is it the scheduling of neutron ports?
14:59:19 <vjay> samuelbercovici: +1
14:59:32 <ptoohill> one note, friends from China cant seem to use google docs. There was a complaint in the ML about it. so we should keep that in mind for future
14:59:40 <sballe_> we'll need meetings Mon, Tues, Wed, etc... Do we schedule these ad-hoc once we get there?
14:59:49 <samuelbercovici> blogan: lest meet after this on openstack-neutron to discuss further
14:59:52 <rm_work> sbalukoff: who knows, maybe I will disagree with jorgem on something on the survey… but since it's not anonymous, he might demote me if I disagree :P
14:59:55 <rm_work> (j/k)
14:59:58 <sbalukoff> ptoohill Good to know!
15:00:07 <jorgem> rm_work: yes! lol
15:00:10 <blogan> samuelbercovici: sounds good to me
15:00:29 <jorgem> alright to the ML we come!
15:00:35 <enikanorov> ok folks, let's wrap up
15:00:35 <mestery> Thanks everyone!
15:00:35 <rm_work> toodles!
15:00:39 <sbalukoff> Haha! Thanks y'all!
15:00:40 <german_> thanks
15:00:40 <ptoohill> bye
15:00:41 <sballe_> bye
15:00:43 <enikanorov> #endmeeting