14:01:52 <enikanorov> #startmeeting neutron lbaas
14:01:53 <openstack> Meeting started Thu Mar  6 14:01:52 2014 UTC and is due to finish in 60 minutes.  The chair is enikanorov. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:56 <openstack> The meeting name has been set to 'neutron_lbaas'
14:02:04 <enikanorov> hi, who is online for lbaas meeting?
14:04:23 <enikanorov> jorgem: hi
14:04:30 <jorgem> hi there
14:05:00 <enikanorov> looks like we don't have a quorum for the meeting yet
14:05:11 <enikanorov> jorgem: do you have any questions on lbaas?
14:05:26 <jorgem> Well, first I wanted to introduce myself
14:05:53 <jorgem> I am Jorge Miramontes, Team Lead of Software Development for LBaaS at Rackspace.
14:06:28 <jorgem> Some of the devs on my team have been in the IRC channel asking questions as we are looking to get involved with you guys!
14:06:29 <edhall> hi
14:06:37 <s3wong> hello
14:07:14 <enikanorov> jorgem: cool, good to see you here
14:07:15 <jorgem> enikanorov: What do you think is the best way to start participating with Neutron LBaaS?
14:07:41 <jorgem> An email may suffice
14:07:43 <enikanorov> jorgem: get familiar with the current state of the code, participate in ML discussions and meetings
14:08:13 <jorgem> sounds good. I'll mostly be listening in on the meeting but just wanted to make you aware of our intenetions
14:08:18 <jorgem> intentions*
14:08:32 <thurloat> o/
14:08:40 <swat30> o/
14:08:43 <enikanorov> ok. so I was expecting some folks to discuss object model proposal
14:08:53 <enikanorov> e.g. continue the discussion from the mailing list
14:09:27 <enikanorov> have you folks read those proposals? do you have any questions or concerns about them?
14:09:29 <vjay> hi enikanorov
14:09:35 <enikanorov> hi vjay
14:09:39 <enikanorov> hi blogan
14:09:46 <blogan> hi enikanorv
14:09:58 <blogan> and enikanorov
14:10:42 <enikanorov> ok, so let me then once again introduce everyone to the problem that we have been discussing recently
14:11:16 <enikanorov> right now we have such object model and public API that your loadbalancer can have one pool (group of nodes) and one VIP
14:11:34 <enikanorov> we need to extend the model and the API to support 2 important use cases:
14:11:58 <enikanorov> 1) ability for 1 pool to have several endpoints with the same IP address
14:12:26 <enikanorov> 2) ability for one VIP to balancer traffic to different pools using L7 protocol rules
14:13:38 <jorgem> To clarify, endpoint = node address? If so, the distinction would be on the node port?
14:13:58 <enikanorov> endpoint is synonym of VIP
14:14:16 <jorgem> thanks
14:14:26 <enikanorov> i intentionally didn't use the word VIP because right now the VIP references neutron port, e.g. IP address
14:14:57 <thurloat> endpoint seems like a better name, since will extend the VIP model to include port and hostname information and have the address reused across multiple VIPs.
14:14:58 <enikanorov> and just saying the we want multiple VIPs for one pool needs clarification that in fact we want to be able to share 1 port
14:15:08 <enikanorov> and create VIPs with different tcp ports and protocols
14:15:32 <enikanorov> thurloat: the proposed name for that is 'Listener'
14:15:54 <vjay> thanks for making it clear on the usecase and terminologies. if you dont mind could you elaborate on the proposals.
14:15:58 <enikanorov> basically we have 2 models (object models and corresponding API) to address usecases #1 and #2
14:16:11 <thurloat> Is the current proposal at https://wiki.openstack.org/wiki/LBaaS/CoreResourceModel/proposal ? That's what I'm looking at now for reference.
14:16:34 <enikanorov> thurloat: no, it's existing model
14:16:41 <enikanorov> let me give a link
14:17:06 <enikanorov> #link https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion
14:17:30 * thurloat looks now
14:17:52 <enikanorov> one proposal is model in 3 or 4.1 (diagrams are similar, cluster and loadbalancer objects on 4.1 are not related to the discussion)
14:18:10 <enikanorov> so picture 4.1 would be more accurate
14:18:28 <enikanorov> another proposal is in the following document:
14:18:43 <enikanorov> #link https://docs.google.com/a/mirantis.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit#heading=h.3rvy5drl5b5r
14:19:15 <enikanorov> the object model is a kind of overloaded with auxiliary objects, but we're mostly interested in VIPs/Pools/members
14:19:27 <enikanorov> others could be skipped from the discussion
14:19:58 <samuelbercovici> hello
14:20:03 <enikanorov> hi Sam
14:20:10 <jorgem> Is the object model for the API side as well as the internal domain or just for the internal domain of Neturon LBaaS?
14:20:25 <vjay> this contains only 2 proposals - loadbalancer instance and vip centric (listener) to solve the problem. If I understand right Sam also made a proposal which does change the current model much
14:20:54 <enikanorov> jorgem: it overlaps with public API
14:21:02 <jorgem> enikanorov: thanks
14:21:21 <samuelbercovici> vjay: I think you mean to say does not change the current model much
14:21:22 <enikanorov> vjay: Sam's proposal doesn't add Listener resource
14:21:50 <enikanorov> vjay: existing model changed in the sense that pools and vips relation is changed to m:n instead of being 1:1
14:22:12 <swat30> enikanorov: why has the LB instance model been disregarded? or has it?
14:22:45 <vjay> sam: yes, *does not
14:22:49 <enikanorov> swat30: community prefer to work in the scope of vips and pools mostly, as I understand it
14:23:12 <enikanorov> basically, VIP-centric proposal is very similar to LB instance
14:23:13 <edhall> enikanorov, is there a proposal for the api?
14:23:37 <enikanorov> edhall: the API is implied, actually.
14:24:09 <edhall> I'm used to working from user stories to api to object model and not the other way around...
14:24:16 <enikanorov> so right now we have to chose between the VIP-centric proposal  (Vips/listeners/pools), and Sam's proposal (Vips/pools)
14:24:19 <blogan> i think a load balancer instance is more clear to a user though
14:24:31 <swat30> I agree
14:24:49 <swat30> and maintains backwards compat
14:24:56 <swat30> which is nice
14:25:27 <enikanorov> samuelbercovici: what do you think about working with lb instance?
14:25:52 <enikanorov> samuelbercovici: btc, the code that introduces the instance is already on review and went through a number of iterations
14:25:59 <enikanorov> and it will preserve VIP/pools resources
14:26:18 <enikanorov> and everything you've planned (L7 stuff bound to Vips)
14:27:02 <samuelbercovici> the chalenge was that lb instance adhers to some notion of implied backend
14:27:16 <enikanorov> no neccessarily
14:27:18 <enikanorov> *not
14:27:21 <swat30> also, could the listener not be introduced into the lb instance solution, which would be attached to a VIP?
14:27:22 <samuelbercovici> both Mark McClain and Salvatore oppused this
14:27:27 <enikanorov> that's purely a logical concept
14:27:30 <samuelbercovici> *opposed
14:27:41 <enikanorov> no, I believe salv-orlando didn't opposed this
14:28:05 <enikanorov> we don't expose any mapping or any notion of the backend
14:28:38 <samuelbercovici> we can restart this all over again and see if Mark or anyone else is now more open to this
14:28:59 <enikanorov> so from API perspective when you want to reuse port, instead of providing vip_id, you provide lb_id
14:29:11 <enikanorov> not much of a difference
14:29:15 <samuelbercovici> to me, tenant, specificaly specifying to which lb-instance a vip belongs is a constarint
14:29:39 <enikanorov> tenant only needs it if he want to reuse the port
14:29:46 <enikanorov> that's exactly the same as in your proposal
14:30:01 <enikanorov> if he don't care about the port - no need to provide lb_id
14:30:47 <samuelbercovici> enikanorov: so can two different IPs be associated to the same lb-insatnce. For example, can 1.1.1.1:80 and 2.2.2.2.80 be associated to the same lb-instance?
14:31:01 <jorgem> If it helps, I was heavily involved in the Atlas API spec with Youcef (Citrix). So, if you have questions for the notion of lb instance I'd be happy to help out. As of right now I need to get a better understanding of the proposals though
14:31:25 <enikanorov> samuelbercovici: i think that could be a limitation of the driver. from API perspective - yes, they can
14:31:42 <vjay> enikanorov, i am a little bit confused here.. which port is this?
14:31:52 <enikanorov> port is neutron port, not tcp
14:32:08 <vjay> why are we talking about neutron port?
14:32:15 <vjay> is it created automatically?
14:32:25 <enikanorov> because we need neutron port to plug vip into the network
14:32:40 <samuelbercovici> enikanorov: so this leads to tenants using lb instances as scheduling
14:32:41 <swat30> I think that the VIP should be similar to the notion of a floating IP, easier to understand from a tenant's perspective IMO
14:32:46 <enikanorov> if we want same IP, but different tcp port, we need to work with the same neutron port
14:32:49 <swat30> can come and go
14:33:03 <enikanorov> samuelbercovici: what do you mean?
14:33:26 <enikanorov> swat30: not sure I get the idea, please explain
14:33:57 <samuelbercovici> If as a tenant I can say 1.1.1.1:80 and 2.2.2.2.80 are on the same lb-instance (note: those are two different VIPs and Services) yjam this means I expec them both on the same place
14:34:14 <samuelbercovici> this is somthing a tenant should not be exposed to
14:34:28 <enikanorov> what you, as a tenant think of as a 'same place'?
14:34:39 <samuelbercovici> what does lb-instance mean?
14:35:03 <jorgem> In my mind an lb-instance is a virtual lb.
14:35:08 <jorgem> Like a virtual box
14:35:18 <enikanorov> it means you unit of logical configuration. that, for instance, offers particular SLA, connected to particular router
14:35:40 <swat30> enikanorov: I think that the VIP solution puts too much emphasis on the IP itself. As a tenant, I want to think of it as a LB that I can change IPs as easily as I can change pool members etc
14:36:16 <swat30> jorgem: my thoughts exactly
14:36:17 <enikanorov> swat30: you can change it
14:36:42 <samuelbercovici> enikanorov: currently the IP can't be changed after VIP creation
14:36:42 <enikanorov> jorgem: well, yes, we need more specific definition in neutron terms
14:37:02 <enikanorov> samuelbercovici: that could be implemented
14:37:06 <jorgem> swat30: So from an object model perspective though should there be an 'lb-instance' object?
14:37:18 <enikanorov> but you're right, looks like it's not there right now
14:37:35 <samuelbercovici> jorgem: the notion of a virtual lb is an implementation specific
14:37:49 <enikanorov> samuelbercovici: so I'm trying to understand, what kind of information we need to 'hide' from the tenant
14:37:55 <swat30> jorgem: just like in the LB instance solution, yes
14:38:02 <enikanorov> samuelbercovici: lb instance is for grouping resources
14:38:06 <samuelbercovici> as a tenat why should I care if 1.1.1.1:80 and 2.2.2.2:80 reside on the same virtual instance?
14:38:08 <enikanorov> samuelbercovici: you use vip_id for that
14:38:15 <enikanorov> i'm going to use lb_id for that
14:38:27 <enikanorov> samuelbercovici: you should not
14:38:39 <enikanorov> and if you don't - don't group them
14:39:17 <samuelbercovici> so why should i be able to say that 1.1.1.1:80 and 2.2.2.2:80 are associate to the same lb-instance if as jorgem implies this represent a virtual applaince?
14:40:08 <swat30> samuelbercovici: maybe as a tenant I have multiple clients/apps that need LBs for different parts. Each client/app will belong to a lb-instance
14:40:10 <swat30> as an example
14:40:12 <enikanorov> why should not you be able? If you care. I don't see why we need to limit that
14:40:34 <samuelbercovici> i understand why 1.1.1.1:80 and 1.1.1.1:443 will be in most common cases served on the same back-end
14:40:45 <enikanorov> yes, in that case you will care
14:40:50 <enikanorov> and you'll group
14:40:57 <enikanorov> in other case - that doesn't matter
14:41:17 <enikanorov> every driver may limit that on driver level, prohibiting to add vips on 2.2.2.2
14:41:34 <enikanorov> but from API perspective - let user decide if he cares
14:41:42 <thurloat> enikanorov agreed.
14:42:21 <vjay> so is it allowed to have the same ip 1.1.1.1:9999 as part of another lb instance?
14:42:24 <jorgem> enikanorov: I agree with that too. API should just abstract the backend. (i.e. simplify it for the API user)
14:42:25 <samuelbercovici> enikanorov: so again, I think tghis is not what a tenant should control.
14:42:50 <swat30> samuelbercovici: why not?
14:42:53 <enikanorov> samuelbercovici: but in your proposal tenant controls it as well
14:42:54 <edhall> instead of specifying the backend, what I would like to see is the ability to specify capacity (e.g. peak bandwidth) and have the appropriate backend choosen
14:43:13 <thurloat> in swat30's example, is a perfect one for why a user would want to control that
14:43:25 <samuelbercovici> enikanorov: in my proposal they only allow specifying IP reuse not grouping of different IPs
14:43:31 <enikanorov> samuelbercovici: don't you see providing vip_id of existing VIP for the new VIP does the same?
14:43:57 <enikanorov> samuelbercovici: API of your proposal doesn't limit that
14:44:06 <enikanorov> but that could be limited on driver level
14:44:26 <samuelbercovici> enikanorov: yes it does, passing the vip_id_1 to a new vip means reusing th IP, a new IP will not be allowed
14:44:56 <enikanorov> well, if you insist, i don't see why we can't do exectly the same limitation for the lb instance
14:45:28 <swat30> could be done via policy maybe?
14:45:49 <enikanorov> the use case of grouping different IPs is not important so i don't care much about that
14:45:59 <samuelbercovici> enikanorov: in that case what is the difference between lb-instance-->vip and vip-->listener ?
14:46:14 <samuelbercovici> besides naming convention?
14:46:29 <enikanorov> exactly, there's none. except names of resources
14:46:47 <enikanorov> with lb instance bw compatibility is even simpler than VIP+listener
14:48:13 <swat30> enikanorov: I could see the grouping being important for certain use cases as well. I think that it logically makes sense for users that need it, and users that don't won't use it
14:48:37 <vjay> enikanorov: can one IP be used in many lb instances?
14:48:43 <enikanorov> swat30: that's my opinion too, I don't quite understand why we can't be flexible here
14:48:53 <enikanorov> vjay: i don't think so
14:49:06 <enikanorov> i mean, within 1 subnet - no
14:49:18 <vjay> that seems to tie some physical aspect to it then
14:49:29 <vjay> jorgem: how was in atlas?
14:49:37 <jorgem> vjay: atlas allowed shared ips
14:49:44 <jorgem> vjay: but different port
14:50:14 <enikanorov> jorgem: different tcp port you mean?
14:50:21 <jorgem> correct
14:50:24 <enikanorov> ok
14:50:25 <vjay> ok. so the notion of VIP remained as Virtual IP (without any tcp port).
14:50:40 <vjay> and whenever an endpoint is created
14:50:46 <vjay> you specify the Virtual IP.
14:50:49 <enikanorov> right now it is both.
14:51:05 <enikanorov> ip+tcp port
14:51:32 <jorgem> yes so port was tied to the lb-instance object while vip was able to be shared amongst instances
14:52:04 <jorgem> lb 1: 1.2.3.4:80 vs lb 2 :1.2.3.4:443 for example
14:52:23 <jorgem> or whatever port the user chose
14:52:35 <enikanorov> it's something we may want to explore, but from impl perspective, I don't see much sense in splitting those between to lbs
14:52:51 <swat30> jorgem: I think that can be accomplished with multiple pools, no?
14:52:55 <jorgem> correct for http/ssl it makes sense to group them
14:53:15 <vjay> i agree
14:53:36 <jorgem> I need to wrap my head on the new definition of terms because atlas had slightly different definitions for vip, pool. node, etc.
14:54:05 <swat30> jorgem: are you referencing this at all? https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion
14:54:24 <jorgem> yes, but I think I need a day to get up to speed on things
14:54:31 <jorgem> sorry for the ignorance!
14:54:38 <swat30> :)
14:55:07 <jorgem> hopefully then I can bring in my atlas experience in a more fruitful manner
14:55:43 <jorgem> enikanorov: For right now though the two proposals are 3 and 4.1 correct?
14:56:12 <thurloat> jorgem we're talking the Loadbalancer instance solution vs. the VIP centric right now
14:56:27 <enikanorov> well, looking at the discussion above, I think we may also consider #2
14:56:27 <jorgem> so 2 vs 3 then
14:56:47 <jorgem> 2,3,and 4.1 lol
14:56:47 <enikanorov> so it creates 3 options
14:57:05 <enikanorov> 3 and 4.1 are same (except for HA stuff that we're not discussing)
14:57:17 <thurloat> well 3 and 4.1 revolve around the same vip core
14:57:20 <jorgem> sounds good. I'll make sure to look at all 3 then
14:57:26 <samuelbercovici> also 1.1
14:57:35 <enikanorov> yep, 1.1
14:58:01 <samuelbercovici> jorgem: please also review my proposal unde 1.1
14:58:06 <jorgem> will do
14:58:09 <enikanorov> samuelbercovici: so if we att the same limitations to lb instance API as you are planning for 1.1 - that, I think, could address both your and mine concerns
14:59:08 <samuelbercovici> enikanorov: can you please update your proposal on the wiki as it currently does not reflecet this? I would also
14:59:20 <samuelbercovici> think on a differen anme than lb-instance
14:59:23 <enikanorov> ok, I will
14:59:25 <vjay> enikanorov: sorry about ignorance. one quick question, do you want some aspect of neutron port represented in the lbinstance.vip? will that solve the problem?
14:59:40 <enikanorov> samuelbercovici: right now it is 'loadbalancer'
14:59:41 <vjay> the problem of placing the VIP?
15:00:23 <enikanorov> vjay: neutron port probably goes from VIP to instance
15:00:37 <enikanorov> ok folks, thanks everyone for attending
15:00:40 <enikanorov> #endmeeting