14:00:45 <enikanorov__> #startmeeting neutron lbaas
14:00:46 <openstack> Meeting started Thu Mar 20 14:00:45 2014 UTC and is due to finish in 60 minutes.  The chair is enikanorov__. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:50 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:50 <obondarev> o/
14:00:55 <avishayb> hi
14:01:02 <crc32> hello.
14:01:29 <edhall> hi
14:01:35 <enikanorov__> hope most of you saw the requirements page
14:01:41 <enikanorov__> #link https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements
14:01:53 <enikanorov__> let's start with discussing the list
14:02:11 <enikanorov__> does anyone have any questions on that?
14:02:28 <jorgem> hello
14:02:31 <enikanorov__> jorgem: hi
14:02:56 <enikanorov__> jorgem: we're going to start with the feature list you've made
14:03:07 <obondarev> should the list include multiple vips per pool in any way?
14:03:11 <jorgem> awesome. did everyone have a chance to add on to it?
14:03:34 <obondarev> i guess it should
14:03:42 <vjay> hi
14:03:52 <enikanorov__> obondarev: yes. that feature is so basic that i missed its absense
14:03:56 <enikanorov__> hi vjay
14:04:11 <jorgem> obondarev: if we can add it so it isn't specific to implementation I don't see why not
14:04:18 <obondarev> enikanorov__: yeah, just thought about it too
14:05:00 <jorgem> It would be nice to capture all requirements in the doc…basic. complex, etc.
14:05:19 <sballe> hi
14:05:31 <enikanorov__> i think the wiki page is actually a good start
14:05:57 <enikanorov__> right now we are yet to implement a very basic features that every lb vendor supports
14:06:01 <jorgem> One thing we need is for everyone to add use cases. I was going to start working on that this coming week from my team's perspective
14:06:16 <enikanorov__> those i marked with High priority
14:06:46 <enikanorov__> jorgem: good. i think for some of the features the use cases are obvious
14:06:57 <jorgem> Correct.
14:07:15 <jorgem> enikanorov: I can back up priorities with data from our current Cloud LB offering
14:07:20 <sbalukoff> Hi guys.
14:07:26 <enikanorov__> hi sbalukoff
14:07:54 <enikanorov__> any other questions on requirements?
14:08:19 <jorgem> enikanorov: What do you think? For example, 90%ish of our load balancers are HTTP/HTTPS which means working on requirements for those would make sense. However, it would be nice to to get all operators' data like that
14:08:23 <sballe> I'll add some use cases around our requirements for more managed services features in LBaaS
14:09:27 <enikanorov__> jorgem: now 'requirements' means requirements for the features itself?
14:09:47 <enikanorov__> intially we were discussing the object model/API and those features are requirements for the obj model
14:09:48 <jorgem> enikanorov: not really, I was thinking backing up priorities with data
14:10:14 <jorgem> enikanorov: The object model discussion should be had, but going forward is what I mean
14:10:35 <enikanorov__> well, I have put priorities based on development considerations. with existing object model we can't really move forward
14:10:54 <enikanorov__> we may however add feature or two, but to add another feature - we'd need to rewrite lots of code
14:11:13 <enikanorov__> it's better to do that in consistent manner where we modify the object model first and then build upon it
14:11:22 <jorgem> enikanorov: Correct, I wanted this page to help organize stuff going forward. Right now we have current development efforts going on and a roadmap.
14:11:50 <enikanorov__> ok.
14:12:14 <enikanorov__> sballe: what is ' more managed services features in LBaaS'?
14:13:34 <jorgem> enikanorov: Do you think breaking the requirements from the two listed perspectives makes sense? Or would you like to break it down another way?
14:14:25 <jorgem> I figured Openstack is for operators which is why I broke it down into user & operator requirements
14:15:00 <sbalukoff> +1 to that
14:15:01 <enikanorov__> you mean to lists of operators and users requirements?
14:15:06 <enikanorov__> yep, that makes sense
14:15:23 <german_> +1
14:15:35 <jorgem> Correct, there are three right now under operator requirements. However, they can probably be broken down further.
14:15:40 <sballe> enikanorov, it just means that as a service provider (hp public cloud)we need to be able ot offer LBaaS as a black box to users. For example we are currently using Libra and the service is manging the HA, resiliency, etc.
14:16:04 <sballe> enikanorov, I will send somethign out to the mailing list for discussion
14:16:16 <enikanorov__> sballe: ok, please do
14:17:00 <sballe> jorgem, +1 FROM ME TOO
14:17:54 <enikanorov__> let's get back to the obj model discussion
14:18:15 <enikanorov__> did you guys have a chance to look over the wiki page?
14:18:15 <sbalukoff> Note that having separate user vs. operator requirements might lend itself to having separate user / operator API experiences. (ie. "operator features" actually make up that "admin API" we've talked about before.)
14:18:23 <jorgem> enikanorov: Sounds good to me. Anything pop out from the doc that affects the object model discussion?
14:18:26 <sbalukoff> The requirements one?  Yes.
14:18:42 <sbalukoff> Oh, the object model one?
14:18:48 <s3wong> enikanorov__: has the wiki page changed since last week?
14:18:48 <sbalukoff> Yes on that, too.
14:19:00 <edhall> monitoring and measurement
14:19:02 <enikanorov__> s3wong: no, but last week some folks were not familiar
14:19:14 <blogan> is there a new wiki for the object model or the same one?
14:19:18 <blogan> ah okay
14:19:19 <blogan> nvm
14:20:06 <enikanorov__> #link https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion
14:20:12 <s3wong> enikanorov__: during last week's meeting there seems to be some consensus on model #2, IIRC?
14:20:19 <sbalukoff> I'm still in favor of option 3, but I've only a minor nit-pick with option 2 on that page, too. Functionally, 2 and 3 are almost the same, but the terminology in 3 makes more sense.
14:20:39 <jorgem> s3wong: +1 Correct
14:21:01 <enikanorov__> sbalukoff: i tend to agree on teminology. i'm in favor of #2 from impl perspective (mode simple)
14:21:19 <rm_work> +1, #2 looks the closest to what I'd like to see as well (also minor nitpicks)
14:21:23 <sbalukoff> I like that in #2, pool isn't inherently tied to a load balancer.
14:21:45 <enikanorov__> sbalukoff: yes, that was actually changed recently
14:21:53 <enikanorov__> after we've discussed that with Sam
14:21:54 <sbalukoff> Oh, cool!
14:21:55 <s3wong> I believe the consensus is that #2 is best for backward compatibility reason
14:22:05 <enikanorov__> markmcclain: hi
14:22:16 <blogan> what terminology do you guys not prefer?
14:22:20 <enikanorov__> avishayb: hi
14:22:39 <enikanorov__> blogan: that's about having IP address on the loadbalancer instead of VIP
14:22:44 <sbalukoff> I prefer to call a tcp service listening on a specific tcp port a 'listener'
14:23:30 <avishayb> enikanorov__ : hi
14:23:39 <sbalukoff> And yes, have the ip address associated with a higher-level object than the object associated with the tcp port.
14:23:47 <blogan> sbalukoff: what about to a less technical user? i'm not so sure listener would be very user friendly
14:24:00 <enikanorov__> blogan: aws has listener
14:24:16 <sbalukoff> (ie. "load balancer" in 2)
14:24:18 <enikanorov__> avishayb: was Sam going to attend?
14:24:21 <blogan> enikanorov: and i would argue aws is not user friendly
14:24:35 <sbalukoff> blogan: Really, a user using a load balancer won't know what a "listener" is?
14:24:37 <sbalukoff> :/
14:24:46 <avishayb> enikanorov__ : no
14:25:00 <jorgem> sbalukoff: It can be made more simple no?
14:25:16 <avishayb> enikanorov__ : he is on his way back from the US now
14:25:28 <rm_work> I would still prefer LoadBalancer to be the high-level object, but maybe I'm old fashioned
14:25:32 <enikanorov__> avishayb: i see...
14:25:41 <blogan> sbalukoff: i've dealth with many users of our clb that don't have a technical backgroudn
14:25:58 <jorgem> enikanorov: Last week you mentioned we needed a core developer to weigh in on the conversation. Do we have one?
14:25:59 <enikanorov__> rm_work: agree here. So i'm concerned that we don't have folks who have objections here on the meeting
14:26:11 <sbalukoff> Mostly, I'd like to see the term "VIP" mean "virtual IP" or "floating IP" like it does in other contexts.  Having it mean what is essentially the same as "listener" when something else more closely matches "virtual IP" is going to be confusing.
14:26:19 <enikanorov__> jorgem: yes
14:26:39 <jorgem> enikanorov: awesome
14:26:51 <blogan> sbalukoff: i do agree though if vip is to be called vip it should probably have an ip address associated with it
14:26:54 <enikanorov__> jorgem: markmcclain has some objections to the proposal #2
14:27:11 <enikanorov__> so we still need to either convince him or get explanations
14:27:33 <rm_work> Yes, VIP should be Virtual IP, and LoadBalancer should be the root object (equivalent to Listener, but easier terminology)
14:27:44 <sbalukoff> explanations with specific points to address would be great.
14:27:57 <rm_work> re-defining VIP for this project is… odd
14:27:58 <enikanorov__> sbalukoff: exactly.
14:28:03 <sbalukoff> It's hard to make someone happy if they don't share that.
14:28:17 <sballe> enikanorov, are the objections by markmcclain listed anywhere?
14:28:24 <crc32> Should ip_address be on vip instead of loadbalancer.
14:28:38 <enikanorov__> sballe: in ML threads i believe
14:28:49 <sbalukoff> crc32: Only if vip *doesn't* have the TCP port associated with it, as well.
14:28:53 <sballe> ok thanks. I'll look for them
14:29:09 <sbalukoff> Specifically, whichever object has the IP address, and whichever has the tcp port should be different objects, no matter what we call them.
14:29:21 <enikanorov__> sballe: so basically some folks say loadbalancer object is an implementation detail that we should not expose to the user
14:29:22 <sbalukoff> (They're going to have too many not-in-common attributes, which is why I say that.)
14:29:26 <enikanorov__> because user doesn't care
14:29:42 <enikanorov__> sbalukoff: agree.
14:30:00 <rm_work> so per crc32, shouldn't IP Address and tcp_port be flipped?
14:30:04 <crc32> so the loadbalancer represents the listening ip while the vip represents the port?
14:30:06 <rm_work> port on the LB and IP on the VIP?
14:30:26 <crc32> that means the loadbalancer has only 1 ip but bunch of ports?
14:30:31 <enikanorov__> rm_work: crc32: IP on LB, port on the VIP
14:30:53 <enikanorov__> 1 ip and many ports, correct
14:30:57 <jorgem> To crc32's point, I'd like to load balancer on both IPV4 and IPv6 addresses (per requirements doc), but #2 has the ip address on the load balancer. How can we address this concern?
14:31:03 <jorgem> for example
14:31:10 <rm_work> enikanorov__: but the opposite should be true
14:31:15 <crc32> so if a user wants multi ips then they use multi vips I guess.
14:31:15 <enikanorov__> jorgem: we can't
14:31:20 <jorgem> enikanorov: :(
14:31:37 <enikanorov__> jorgem: so here's the problem
14:31:45 <rm_work> still not understanding the redefining of VIP to mean… not VIP
14:31:52 <enikanorov__> we need to store neutron port in some object (LB or VIP)
14:32:07 <rm_work> right, so store that in LB? and put IP with VIP....
14:32:18 <sbalukoff> rm_work: This is to try to maintain backward compatibility, I think.
14:33:05 <rm_work> alright, maybe there's something I don't understand about the way neutron works (i'm kind of new), but still not getting why VIP != Virtual IP (and thus storing the IP Address)
14:33:12 <sbalukoff> rm_work: However, I'm with you on not understanding why we don't take this opportunity to fix the terminology. :)
14:33:26 <crc32> sorry I meant to say if a user wants multi IPs they need multi loadbalancers then.
14:34:01 <crc32> Yea layer1 ports and tcp/udp parts are confusing me.
14:34:06 <enikanorov__> crc32: the idea is that user doesn't care about whether it is multiple LBs or not
14:34:32 <enikanorov__> i don't share that opinion, btw
14:34:37 <rm_work> we may have very different users <_<
14:34:55 <sbalukoff> Yep. Mine seem to understand what a 'listener' is, for example. ;)
14:35:03 <enikanorov__> i think if user cares about amount of LBs they consume - then it's good to give them such ability to group resources to 1 backend
14:35:18 <crc32> If by listener you mean listening on port 80 then sure I'm all for it.
14:35:45 <enikanorov__> listener is tcp port + protocol + protocol parameters (like ssl certs, etc)
14:35:48 <sbalukoff> crc32: Yep, that's what I mean with 'listener'
14:36:23 <jorgem> enikanorov: So this one of the reasons I wanted requirements doc. People have different understandings on #1) terminology and #2) how a load balancer should be abstracted. If requirements are met from all parties (hypothetically speaking) then we should be able to come to a consensus…I hope :)
14:37:03 <sbalukoff> jorgem: I'm with you on the wanting IPv4 + IPv6, as well, in my model I solve that as having IPv6 address be an additional option attribute that goes in the same object that has the IPv4 address.
14:37:09 <enikanorov__> jorgem: agree
14:37:16 <sbalukoff> Pretty simple solution, if you ask me. :/
14:37:19 <sdague> when we get to a natural break point, in the flow, I need to raise an issue with lbaas causing resets in the gate
14:37:28 <enikanorov__> btw, on second thought i might be wrong
14:37:41 <sbalukoff> But then, I'm also not as familiar with 'neutron ports' as I could be, eh.
14:37:46 <enikanorov__> looking at the neutron model i see that network may have subnets version both 4 and 6
14:38:01 <enikanorov__> which means that port may have addresses from 2 subnets of different ip versions
14:38:04 <jorgem> enikanorov: A glossary would be a good thing for the wiki too I think.
14:38:12 <sbalukoff> jorgem: I also agree that talking requirements is the way to go to get consensus.
14:38:16 <sballe> +1 on the glossary
14:38:24 <enikanorov__> ok, i'll add such page
14:38:24 <rm_work> +1 glossary, +1 reqs
14:38:37 <crc32> +1 glossary
14:38:42 <tvardeman> +1 glossary
14:38:45 <blogan> -1 glossary
14:38:47 <blogan> j/k
14:38:48 <enikanorov__> #help
14:38:50 <rm_work> someone can define for me what VIP means here <_<
14:38:50 <sbalukoff> +1 glossary
14:38:57 <german_> +1 glossary
14:39:06 <openlurk> +1 glossary
14:39:14 <enikanorov__> #action enikanorov to add glossary to lbaas wiki
14:39:51 <sbalukoff> rm_work: Yes. In 'legacy LBaas' it means ip address + tcp port + protocol attributes.  We're contemplating breaking it apart into separate objects so it doesn't mean that anymore.
14:40:14 <jorgem> enikanorov: I think we need to pin point which requirements affect the converstation and then perhaps continue it on the ML?
14:40:18 <rm_work> WTB: VIP = Virtual IP, how much rework would that actually be? insanity?
14:40:31 <crc32> Listener sounds lijke a good term.
14:40:34 <sbalukoff> rm_work: The complication is that 'VIP' is a very meaningful attribute in the legacy code.
14:40:57 <rm_work> hmm, so
14:41:20 <rm_work> we're 100% committed to backwards compatibility from this point? no chance of a "v2"?
14:41:23 <sbalukoff> Well, ans the legacy API. Again, we're trying not to break backward-compatibility.
14:41:28 <enikanorov__> jorgem: yes, it mostly were done like 3 meetings ago, but from that time attendees have changed :)
14:41:55 <enikanorov__> jorgem: obj model discussion targets two major features: multiple vips per pool and multiple pools per vip (L7 rules)
14:42:13 <sbalukoff> I would be willing to break backward compatibility to get the features (ie. requirements) we need. But then again, we don't have a whole lot of users on Neutron LBaaS yet (precisely because it doesn't have all the features our customers need, yet.)
14:42:47 <enikanorov__> bw compatibility is important
14:42:54 <rm_work> right, i thought at this point would be the best time to DO api breaks
14:43:00 <rm_work> before it is in heavy(er?) use
14:43:02 <jorgem> sbalukoff: That makes sense to a degree.
14:43:07 <blogan> is there any way to version the api?
14:43:20 <enikanorov__> i also think it's possible to evolve rather then just to the cutoff
14:43:35 <sbalukoff> I think we can totally keep backward-compatible workflows.
14:43:38 <enikanorov__> to=do
14:43:39 <rm_work> right, but if we're talking about something central like VIP, evolution may not be 100% possible?
14:43:55 <jorgem> enikanorov: +1, Evolving is going to constantly happen so we better get in the groove of it now
14:43:57 <enikanorov__> it is possible, actually
14:44:05 <sbalukoff> But I'd love to fix the terminology, even if that means existing users of the service need to update their code to work with different terms in the API.
14:44:17 <enikanorov__> ok, I'll do the glossary
14:45:15 <blogan> enikanorov: is there anyway to version neutron lbaas outside of neutron itself being versioned?
14:45:27 <edhall> sbalukoff, isn't terminology more a concern for a client application, not an API?
14:45:38 <enikanorov__> blogan: i'm not sure it's possible right now
14:46:07 <sbalukoff> edhall: I think so too--  but you'll always get grumbling from users if they have to update their client application code.
14:46:09 <enikanorov__> blogan: everything is v2.0 afaik
14:46:55 <edhall> I'm not in the habit of controlling things by typing restful URLs manually
14:46:59 <vjay> I think we should allow more than one loadbalancers to use the same VIP. It gives flexibility in management by creating many loadbalancers for the same IP for the user.
14:47:16 <vjay> jorgem: how was it in atlas?
14:47:18 <enikanorov__> vjay: what's the use case?
14:47:30 <vjay> it keeps it logical.
14:47:46 <vjay> i should be free to create 2 logical loadbalancers
14:47:46 <jorgem> vjay: LB has many vips
14:47:58 <jorgem> where vip = address + port
14:48:12 <sbalukoff> vjay: I think we're getting confused as to what our terms mean, again.
14:48:23 <enikanorov__> VIP shared by 2 LBs - that's something i not sure i understand
14:48:27 <enikanorov__> (unless it's HA)
14:48:47 <enikanorov__> and HA is not just 2 LBs for the same VIP
14:48:52 <vjay> i would like to create a LB with (IP1) and Pool1
14:48:57 <jorgem> vjay: sorry my mistake lb had port vips just had address
14:49:07 <vjay> and another with LB with (IP1) and Pool2
14:49:07 <blogan> multiple pools would solve that right?
14:49:25 <rm_work> atlas: VIP = Address, LB = Port, LB 1 <-> n VIP
14:49:27 <jorgem> blogan: multiple pools should solve that
14:49:31 <enikanorov__> vjay: tcp ports are different?
14:49:39 <vjay> yes
14:49:44 <vjay> tcp ports are differnt
14:49:49 <enikanorov__> then it's 1 LB and two VIPs
14:50:30 <vjay> i understand that enikanorov. but why have the restrication. a user should be able to create 2 LBs with one VIP each as well
14:50:32 <enikanorov__> ok folks, I'd like to give a word to sdague who has something (bad) to say about lbaas in the gate
14:50:40 <enikanorov__> sdague: hi
14:50:45 <vjay> if we wants to reuse the pool, he can keep it in one LB
14:50:47 <sbalukoff> I think that glossary will do wonders to help eliminate confusion from this discussion. :)
14:51:05 <blogan> sbalukoff: agreed
14:51:09 <crc32> we can start with the definition of a vip.
14:51:18 <enikanorov__> vjay: if he doesn't want to reuse the pool, it is still 1 LB
14:51:30 <enikanorov__> but with two different pools for each of VIPs
14:51:55 <edhall> sbalukoff, absolutely
14:52:22 <sdague> enikanorov__: http://logstash.openstack.org/#eyJmaWVsZHMiOltdLCJzZWFyY2giOiJtZXNzYWdlOlwiRkFJTDogdGVtcGVzdC5zY2VuYXJpby50ZXN0X2xvYWRfYmFsYW5jZXJfYmFzaWMuVGVzdExvYWRCYWxhbmNlckJhc2ljLnRlc3RfbG9hZF9iYWxhbmNlcl9iYXNpY1wiIEFORCB0YWdzOmNvbnNvbGUiLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsIm9mZnNldCI6MCwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjEzOTUzMjY2Nzg3MTd9
14:52:33 <sdague> basically the lbaas is failing a bunch
14:52:47 <sdague> https://bugs.launchpad.net/neutron/+bug/1295165 is now filed
14:52:48 <uvirtbot> Launchpad bug 1295165 in neutron "lbaas is unreliable in the gate" [Critical,New]
14:52:54 <sdague> we need someone on it
14:53:12 <enikanorov__> ok, thanks. we'll prioritize this one
14:54:13 <vjay> ok. I understand how we can acheive that using current model. but I am afraid we are bringing implementation details in to the logical model. which might not be liked by marck or other core members.
14:54:38 <enikanorov__> vjay: what kind of impl detail do you see we'd bring?
14:54:39 <vjay> +1 on glossary
14:54:52 <enikanorov__> should I +1 on glossary too? :)
14:55:08 <sbalukoff> enikanorov__: If it helps. ;)
14:55:10 <blogan> enikanorov: yes or it wont be done
14:55:18 <vjay> what is the reason to restrict 1 VIP ( i mean ip address) to one LB?
14:55:27 <vjay> i thought it was due to implementation
14:55:30 <enikanorov__> i'll try to do it without +1ing it :)
14:55:45 <vjay> ?
14:55:55 <enikanorov__> vjay: that was discussed once
14:56:10 <enikanorov__> basically the restriction somewhat tied to how things work
14:56:26 <enikanorov__> but it goes down to sharing a neutron port between backend
14:56:38 <vjay> that is implementation detail :-)
14:56:53 <enikanorov__> when you say, 'logic LBs' the only meaningful use case would be two create the LB without deploying it
14:56:53 <sbalukoff> vjay: Is there any implementation in the world that works differently?
14:57:08 <edhall> vjay, so is your use case HA?
14:57:14 <enikanorov__> that was discussed at the summit once, it decided that we don't want that
14:57:34 <vjay> i think we are running short of time. i will send an email.
14:57:41 <enikanorov__> and yes, HA is not something that should be managed by hand
14:57:47 <enikanorov__> VIP reuse != HA case
14:58:06 <sbalukoff> agreed.
14:58:14 <vjay> yes
14:58:19 <vjay> not HA case
14:58:22 <edhall> gotcha, just trying to figure out vjay's objection
14:58:25 <enikanorov__> #action vjay to write to ML about VIP reuse
14:58:52 <vjay> VIP will be placed in the same backend.
14:59:03 <jorgem> Also, everyone please update the requirements doc when you get a chance.
14:59:04 <jorgem> #link https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements
14:59:09 <vjay> just that it wont be part of the same loadbalancer
14:59:12 <vjay> in the logical model
14:59:29 <sbalukoff> Thanks for creating that, jorgem!
14:59:44 <jorgem> sbalukoff: you are quite welcome!
14:59:47 <enikanorov__> vjay: i see. that's too flexible then
15:00:09 <enikanorov__> i mean like right now we have health monitors assiciated with the pool
15:00:16 <enikanorov__> we will have vips associated with LBs
15:00:30 <enikanorov__> imo that's beyond the real need...
15:01:29 <enikanorov__> ok. thatnks everyone
15:01:31 <enikanorov__> #endmeeting