14:00:43 <enikanorov_> #startmeeting neutron lbaas
14:00:44 <openstack> Meeting started Thu Mar 13 14:00:43 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:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:47 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:57 <enikanorov_> hi
14:00:59 <obondarev> hi
14:01:02 <s3wong> hello
14:01:04 <jorgem1> hello
14:01:06 <blogan> hello everyone
14:01:09 <vjay> hi
14:01:09 <edhall> hi
14:01:36 <enikanorov_> let's start with some announcements
14:01:47 <enikanorov_> #topic announcements
14:02:10 <enikanorov_> we've got new driver in our tree - netscaler from citrix
14:02:27 <enikanorov_> which is backed by their 3rd party CI
14:02:37 <enikanorov_> congrats to the authors
14:03:01 <vjay> thanks enikanorov!
14:03:12 <obondarev> embrane driver is close to merge too
14:03:16 <enikanorov_> another driver can possibly make it to Icehouse: embrane
14:03:20 <enikanorov_> did it get FFE?
14:03:24 <obondarev> yes
14:03:27 <enikanorov_> good
14:03:43 <enikanorov_> so all that is a good indication that community is interested
14:04:06 <enikanorov_> at the same time each new driver increases the cost of object model and API change that we're discussing
14:04:38 <enikanorov_> anyway... we also have radware drive the still doesn't have working and voting CI
14:05:07 <enikanorov_> I saw tempest patch was merged that resolves some problems with integration testing of radware driver
14:05:17 <enikanorov_> so I hope to see their CI voting soon
14:05:42 <enikanorov_> i think we'll not be glad if core team desides to remove the driver from the tree
14:06:07 <enikanorov_> #action Sam to update on progress with radware CI
14:06:59 <enikanorov_> that's it on announcements
14:07:07 <enikanorov_> lets get back to the object model discussion
14:07:34 <enikanorov_> the diagrams and proposals are on the wiki, I think most of you are already familiar with them
14:08:08 <enikanorov_> Sam Bercovici could not attend
14:08:16 <enikanorov_> does anyone have any questions/suggestions on the object model proposals?
14:08:47 <blogan> after looking at them more carefully i believe proposal #2 is the best
14:09:19 <obondarev> given that new drivers are merged I thiink one of the main requirements to the new model should be backward compatibility
14:09:39 <jorgem> Proposal 2 is backwards compatible no?
14:09:49 <enikanorov_> yes, it is
14:09:51 <obondarev> it is
14:10:22 <obondarev> so as #3
14:10:24 <blogan> what were the cons of proposal 2?
14:10:29 <enikanorov_> however after recent discussions I realized that code on review should be improved in order to coply with recent design decisions
14:10:47 <iwamoto> shouldn't we discuss at API level first?
14:10:58 <enikanorov_> blogan: some folks argue the the 'loadbalancer' object is redundant
14:11:03 <jorgem> Proposal 3 doesn't allow multiple vips in an intuitive manner which is a big detractor for me.
14:11:24 <blogan> enikanorov_: could you explain how it is redundant?
14:11:26 <enikanorov_> iwamoto: API maps very closesy to object model, so it's kind of joined discussion
14:11:52 <jorgem> enikanorov: Doesn't it make sense though that Load Balancer as a Service have a load balancer object?
14:11:58 <enikanorov_> blogan: well, some folks think that all user cares is Vips and Pools
14:12:04 <jorgem> it's in the name of the service
14:12:16 <enikanorov_> jorgem: that's a weak argument :)
14:12:18 <jorgem> and most people speak in terms of a loadbalancer object
14:12:26 <jorgem> :) just saying
14:12:41 <enikanorov_> I agree, but I also want to make sure concerns and objections are addressed
14:13:06 <s3wong> I think for a user perspective, "listener" is more familiar for those that had used AWS ELB
14:13:10 <blogan> fair enough, all objections should be addressed and not dismissed
14:13:11 <jorgem> enikanorov: Should we talk about it proposal one by one then?
14:13:14 <jorgem> each*
14:13:23 <enikanorov_> so basically proposals #2 and #3 address the same problem of reusing same ip address by several vips
14:13:32 <enikanorov_> in #3 vips are called 'listeners'
14:14:19 <enikanorov_> so to me #2 and #3 are basically the same, except of object names
14:14:43 <enikanorov_> that's why I'd prefer #2 because bw compatibility is achieved more easily
14:15:16 <enikanorov_> s3wong: yes, I stole 'listener' from aws api
14:15:24 <youcef> and the fact that #3 is not backward-compatible
14:15:41 <obondarev> why?
14:15:42 <enikanorov_> youcef: it can be made bw compatible
14:15:46 <s3wong> how can #3 be backward compatible?
14:16:05 <enikanorov_> s3wong: when you create VIP, you also create first listener
14:16:10 <youcef> how?
14:16:14 <enikanorov_> so 1 call will result in 2 objects created
14:16:48 <youcef> ok
14:16:53 <s3wong> hmm... I see
14:17:17 <blogan> in proposal #2 a user would have to create a pool, member, vip and load balancer correct?
14:17:40 <enikanorov_> loadbalancer is also created automatically (for the VIP)
14:17:53 <enikanorov_> because we want to preserve existing workflows
14:17:54 <jorgem> From the docs: "However this approach doesn't address multiple VIPs in one configuration. For this purpose another entity 'Listener' is introduced." It seems like 2 simplifies this
14:18:21 <enikanorov_> jorgem: yes, but that's mostly about resource names (from API perspective)
14:18:42 <enikanorov_> from implementation perspective it's easier to add another simple object like loadbalancer than to do renaming
14:18:49 <jorgem> enikanorov: Correct, but if 2 and 3 perform the same thing I'd be in favor of simplifying it
14:18:57 <enikanorov_> me too
14:19:21 <jorgem> enikanorov: So I agree with you that 2 is better.
14:20:06 <jorgem> To clarify the L7VipPoolAssoc is for L7 switching right?
14:20:16 <enikanorov_> jorgem: yes
14:20:24 <jorgem> thanks
14:20:37 <enikanorov_> jorgem: that's the way of specifying several pools that are chosen based on L7 traffic processing
14:21:05 <enikanorov_> markmcclain: hi
14:21:55 <jorgem> enikanorov: With proposal 2 then, do multiple vips point to the same pools? For example, I want to have both and IPv4 vip and an IPv6 vip point to the same pool
14:22:24 <enikanorov_> jorgem: that's a good question
14:22:44 <jorgem> I believe it can be made to do that but the UML needs to be updated
14:22:55 <enikanorov_> initially main use case for multiple vips in one instance was Ip address sharing
14:23:18 <enikanorov_> so I'm not sure about Vips having different addresses
14:23:56 <enikanorov_> and yes, if we want to support it - the diagram needs to be updated
14:24:20 <jorgem> enikanorov: Okay, just wondering because IPv6 compatibility would be nice
14:24:31 <youcef> yes, I think we should support it, it's a common use case, especially with ipv4/ipv6 addresses.
14:24:46 <enikanorov_> well, from api/obj model perspective it is ipv6-compatible
14:25:00 <enikanorov_> jorgem: good to know.
14:25:02 <youcef> I mean having both for the same pool
14:25:09 <enikanorov_> btw
14:25:21 <enikanorov_> we also decided to make pool pure logical object
14:25:30 <enikanorov_> e.g. it can be shared between balancers
14:25:49 <enikanorov_> which means that you can have ipv4 and ipv6 vips pointing to the same pool, but on different loadbalancers
14:26:28 <youcef> I thought that loadbalancer is now the root object, which means it decides the provider chosen?
14:26:41 <enikanorov_> i discussed the ability of having several vips with different ip addresses and Sam was against that
14:26:45 <blogan> with that though, having to have two load balancer instances to get two vips pointed to the same pool would be confusing to a user
14:26:54 <enikanorov_> youcef: yes, loadbalancer is the root object
14:27:26 <youcef> if we use 2 loadbalancers, there is a change that the providers will be different.
14:27:37 <enikanorov_> right...
14:27:47 <youcef> I mean for the 2 addresses of the same pool.
14:27:50 <blogan> which i think is fine, it'd be a different flavor load balancing the same pool
14:28:33 <vjay> i think there will be practical difficulty in implementing this
14:28:37 <vjay> for ex. statistics
14:28:39 <vjay> of the pool
14:28:44 <enikanorov_> vjay: you're right
14:28:50 <enikanorov_> we're also discussed that with Sam
14:29:00 <youcef> but what if the flavors correspond to different drivers? how could this be implemented?
14:29:07 <enikanorov_> statistics should be seriously refactored
14:29:12 <jorgem> vjay: stats are measured from the vip perspective that's why right?
14:29:54 <enikanorov_> youcef: that's why loadbalancer object could drive the resource to the existing configuration
14:30:12 <youcef> but there are now 2 loadbalancers :)
14:30:33 <vjay> jorgem: today it is totally based on pool. inorder to understand the traffic sent to the pool members.
14:30:38 <enikanorov_> youcef: you mean ipv4 and ipv6?
14:30:46 <youcef> yes
14:31:26 <enikanorov_> we need to consider allowing such vips under one balancer, but in that case it would not be different from multiple ipv4 addresses within a loadbalancer
14:31:54 <enikanorov_> and in that case I  suppose it makes sense to allow that, and each driver will decide if it supports it
14:32:15 <youcef> enikanorov: I agree
14:32:16 <enikanorov_> on the other hand it could also be confusing to the user if certain driver doesn't support that
14:32:33 <enikanorov_> because you don't know the driver, you only provide flavor
14:32:42 <enikanorov_> (we're talking about our bright future)
14:34:04 <youcef> yes, if we add it, multiple vips per pool will need to be supported by all drivers.
14:34:36 <enikanorov_> that's I'd say could be limitation of flavor mechanism
14:34:44 <enikanorov_> or a requirement...
14:35:09 <jorgem> enikanorov: Is the goal for the meeting to decide on proposal or to discuss the merits of each one? (I just want to understand what the process is since I'm relatively new to this)
14:35:13 <enikanorov_> i mean that flavor should contain a requirement for the  driver to support multiple vips per loadbalancer
14:35:39 <enikanorov_> jorgem: in general we all need to agree on a certain design.
14:36:05 <enikanorov_> It's also important to get the opinion of some core team mebmers who participate in code reviews
14:36:29 <jorgem> enikanorov: Perhaps we can come up with what requirements we all need in order to guide our decision?
14:36:38 <jorgem> enikanorov: Let me know if there is a place already for this.
14:36:48 <enikanorov_> markmcclain was generally interested in that discussion and he has objections to #2, but it seems he's busy right now to explain detail of his objections.
14:37:05 <enikanorov_> jorgem: it's mailing list mostly
14:38:46 <enikanorov_> so basically we're meeting here to discuss details and form a decision, but we also need some other folks who should agree
14:38:49 <jorgem> enikanorov: Gotcha, would you be opposed to have a requirements page? I think that might bring some clarity as to why we will have a certain object model.
14:39:11 <enikanorov_> sure I would not
14:39:49 <jorgem> enikanorov: For example, the IPv4/IPv6 requirement.
14:40:04 <enikanorov_> I think we'd be glad to see such page which will help us and any newcomers to understand the problems that we're trying to solve
14:41:09 <youcef> by the way, I don't think we should limit the use case of multiple vips per pool to the ipv4/ipv6 use case, it could be internal/external vip or any other use case.
14:41:41 <jorgem> youcef: correct. I would consider that another requirement.
14:42:12 <enikanorov_> ok, no objections on this one
14:42:31 <iwamoto> what's a "requirement page"?
14:42:52 <enikanorov_> iwamoto: i think it's some wiki page that jorgem is willing to create :)
14:43:10 <jorgem> iwamoto: My idea is that we capture what functionality everyone wants.
14:43:51 <jorgem> Then, as we look at the proposals we see which ones satisfy those requirements (conceptually speaking as of right now)
14:44:29 <jorgem> I'm just suggesting this because we all have different use cases and it will help communicate everyone's intentions of using Neutron LBaaS
14:44:52 <iwamoto> listing required functionalities sounds great
14:45:00 <jorgem> enikanorov: Could I email you offline for suggestions on how to create such a page?
14:45:08 <enikanorov_> yes, i totally support this idea
14:45:16 <s3wong> jorgem: sounds good. An action item for you then :-) ?
14:45:28 <jorgem> yes
14:45:48 <enikanorov_> jorgem: well... it's wiki, if you have launchpad id, you can log in and create the page. sure you can email me, we acn also discuss the requirements
14:45:48 <jorgem> #action Jorge to start a requirements wiki page
14:47:24 <enikanorov_> ok, anything else to discuss?
14:47:37 <blogan> enikanorov_: are there core reviewers for neutron lbaas? or is it neutron core reviewers that review the plugins as well?
14:48:11 <enikanorov_> anyone can review the code, we have obondarev who is neutron core and is lbaas key contributor
14:48:22 <youcef> enikanorov: will proposal 2 need to be changed so the diagram to allow a n:m relationship between vip and pool?
14:49:09 <enikanorov_> youcef: it already has m:n actually. it may not be obvious, because 1:1 is from vip to default pool, but through l7 you can have vip-> many pools
14:49:56 <youcef> enikanorov: I mean the opposte,  many vips -> 1 pool
14:50:27 <enikanorov_> that's achievedby multiple vips within loadbalancer
14:50:38 <enikanorov_> each vip can have same default pool
14:50:47 <enikanorov_> of multiple pools via l7 rules
14:51:10 <enikanorov_> so it's not a direct relationship, but though loadbalancer/l7 rules instead
14:51:11 <youcef> ok, it wasn't obvious to me :) may be then add some text to this effect.
14:53:08 <vjay> if option 2 is introduced, can pool exist independently? pool will be always be in scope of a loadbalancer right?
14:53:36 <enikanorov_> vjay: currently the idea is to have pool as a logical object, e.g. it's not bound to the loadbalancer
14:53:43 <enikanorov_> so it can exist out of scope of loadbalancer
14:54:02 <obondarev> just like health monitor as it is now
14:55:46 <jorgem> obviously we won't be able to capture every requirement. However, we can prioritize them and work that way
14:55:46 <jorgem> How does everyone think we should scope the requirements? Overall functionality or specific to the object model discussion?
14:55:57 <youcef> Does that mean you can have loadbalancers that have been created with different flavors (and therefore potentially using different drivers) use the same pool?
14:56:17 <enikanorov_> jorgem: i think it makes sense to prioritize them
14:56:44 <enikanorov_> main requirements lay around basic functionality of multiple vips, multiple pools and ip address reuse
14:57:05 <enikanorov_> youcef: yes
14:57:29 <enikanorov_> youcef: that redefines some aspects of existing workflows, that is understood
14:58:02 <enikanorov_> youcef: also i'm thinking about limiting this ability at first step
14:58:09 <youcef> so, is the pool reimplemented on each driver? what would be the statistics/status of the pool in this case?
14:58:41 <youcef> enikanorov: yes I agree, I think we shouldn't allow this, it can be confusing.
14:58:45 <enikanorov_> youcef: yes, that's the question that comes first. It gets complicated.
14:59:13 <enikanorov_> we have discussed these aspects with Sam, it is solvable, but requires quite a bit of work
14:59:35 <obondarev> youcef: are you familar with Sam's proposal? He tried to address that statistics concerns there
14:59:57 <youcef> I also don't see a valid use case for wanting to do this (using different flavors for same pool).
14:59:57 <blogan> i think limiting it at first is the right approach and if it ever becomes something that users want then we can do it
15:00:53 <youcef> obondarev: I looked at it, but can't say I'm familiar with it :)
15:02:02 <enikanorov_> ok we need to wrap up
15:02:09 <enikanorov_> thanks everyone for attending
15:02:11 <enikanorov_> #endmeeting