14:00:27 <enikanorov_> #startmeeting neutron lbaas
14:00:28 <openstack> Meeting started Thu May 29 14:00:27 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:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:32 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:32 <dougwig> morning
14:00:49 <enikanorov_> #link https://wiki.openstack.org/wiki/Network/LBaaS#Agenda
14:01:03 <xgerman_> morning
14:01:03 <enikanorov_> this is the agenda for the meeting
14:01:24 <enikanorov_> blogan: do you want to give an update on the blueprint?
14:01:35 <blogan> sure
14:02:01 <blogan> i updated the BP to reflect the change to 1:M LoadBalancer to Listener
14:02:26 <enikanorov_> is there an agreement on N:M vs 1:M?
14:02:27 <blogan> Unless there are objections to this, I assume thats the way we want to go for now at least
14:02:54 <vivek-ebay> +1 for 1:M
14:02:59 <Youcef> can you put a link to the updated blueprint (#link)?
14:03:00 <xgerman_> +1 for 1:M
14:03:02 <jorgem> agreed
14:03:05 <dougwig> +1 1:M
14:03:12 <enikanorov_> Youcef: https://review.openstack.org/#/c/89903/8/specs/juno/lbaas-api-and-objmodel-improvement.rst
14:03:16 <blogan> sbalukoff did wonder if we should put IPv4 and IPv6 addresses on the load balancer object
14:03:25 <blogan> I'd like to get everyone's thoughts on that
14:04:14 <blogan> anyone have thoughts?
14:04:18 <sbalukoff> I'd be for it. :)
14:04:24 <blogan> lol
14:04:27 <jorgem> hmm
14:04:30 <xgerman_> two addresses per node or mixed adresses or both?
14:04:32 <Youcef> #link  https://review.openstack.org/#/c/89903/8/specs/juno/lbaas-api-and-objmodel-improvement.rst
14:04:43 <sbalukoff> Mixed addresses.
14:04:50 <enikanorov_> i thought that was initial idea, but then we switched to single address per LB
14:04:52 <jorgem> If you wanted many ip addresses then it now seems weird if you do that
14:04:59 <sbalukoff> So, up to one IPv4 and one IPv6
14:05:03 <jorgem> I like single
14:05:07 <dougwig> depends on how much code it would take; i'd rather take the smallest bite that we can, and nail it.
14:05:07 <xgerman_> me, too
14:05:09 <jorgem> simpler
14:05:13 <xgerman_> just wanted to clarify
14:05:15 <Youcef> jorgem: agree, me too
14:05:35 <jorgem> just create another lb if you want IPv6
14:05:39 <jamiem> I agree
14:05:47 <xgerman_> +1
14:06:08 <enikanorov_> but then N:M may make sense
14:06:13 <Youcef> Is there a type of ipaddress to know whether you are reading an IPv4 or an IPv6?
14:06:13 <blogan> So what would we miss out on if we didn't have the IPv6 on the load balancer?
14:06:26 <enikanorov_> (i mean LB:Listener relation)
14:06:41 <blogan> enikanorov_: yeah that was the main reason for that relationship
14:07:28 <samuelbercovici> hello!
14:07:29 <sbalukoff> blogan: It's more work for the user to maintain two identical listners + sub objects.
14:08:05 <blogan> sbalukoff: yes that is one big reason
14:08:29 <sbalukoff> It's also extremely common for back-ends that can do IPv6 ro be able to do both IPv4 and IPv6.
14:08:35 <samuelbercovici> I think that starting with 1:N with aim of moving to M:N is not good
14:08:50 <enikanorov_> samuelbercovici: agreed.
14:08:58 <blogan> samuelbercovici: what do you think about an ipv4 address and ipv6 address on the load balancer object?
14:09:00 <jorgem> Having IPv4 and IPv6 on the same lb makes sense for one use case. However, when considering the myriad of use cases (i.e. combination of single to multiple ip address) then you have an inconsistent way of doing things. For example, you could technically have 2 ways of loadbalancing 1) One lb with IPV4 and IPv6 or 2) One lb with IPV4 (IPV6 nulled out) and one with IPv6 (IPv4 nulled out). I think this becomes confusing.
14:09:53 <enikanorov_> i think N:M should be ok. If user want advanced use case (ipv4+ipv6) its fine to let em deal with some API complexity around it (like attaching listeners to another LB)
14:09:54 <sbalukoff> jorgem: I don't think it's that confusing. you've actually just listed all the possible permutations.
14:10:00 <samuelbercovici> if we take out implementaion efforts, I think that the M:N relashionship is the correct one
14:10:37 <jorgem> sbalukoff: What if I wanted more than 2 ip addresses (some of customers do this and I don't know why really)
14:10:49 <blogan> samuelbercovici: are you advocating we start with the M:N relationship from the beginning?
14:11:01 <samuelbercovici> blogan: yes
14:11:05 <sbalukoff> I"m just having a hard time seeing many actual practical cases where N:M will actually be used other than the one IPv4 + one IPv6 case.
14:11:16 <xgerman_> me, too
14:11:20 <sballe_> sbalukoff: +1
14:11:23 <dougwig> +1
14:11:25 <xgerman_> and ther eis a workaround with two lbs
14:11:34 <aburaschi> Sorry for asking, but what would be the use case for M:N, in short words?
14:11:50 <Youcef> so why then do we want to go eventually to M:N? what is the use case that cannot be accomplished?
14:12:20 <blogan> aburashci: it allows a user to reuse a listener thats already assigned a load balancer, so they don't have to redo their configuration for a load balancer with an IPv6 vip
14:12:54 <jorgem> if its edge case then I'm fine. Just wanted to see if anyone else had a strong position on it. Now that I think about it I'm not really adamant about it.
14:12:59 <blogan> Youcef: If we do the IPv6 and IPv4 attribute I'd suggest we don't go to the M:N
14:13:09 <samuelbercovici> aburaschi: in addition to ipv4+ipv6- a User wants to expose his application to the internet on one network using a virtual ip and then expose the same application on a different network facing only internal users
14:13:15 <sbalukoff> My point is that I don't see a reason for N:M *except* for the IPv4 + IPv6 use case being discussed. So, I'm a fan of 1:N only, with the caveat that "1" in this case is an entity that can have up to one IPv4 and one IPv6 address.
14:13:28 <enikanorov_> samuelbercovici: good point
14:13:47 <Youcef> blogan: but even if we don't, we can still accomplish the ipv4+ipv6 with 2 lbs, right?
14:13:55 <aburaschi> samuelbercovici and blogan, thanks, that make sense.
14:13:56 <dougwig> if i've got two network configs, is it reasonable to expect to share a listener?
14:14:17 <vivek-ebay> @Youcef, not unless we implement N:M
14:14:21 <samuelbercovici> dougwig: well, its the exactly same application
14:14:28 <sbalukoff> samuelbercovici: In that use case, which seems a little contrived to me, I would say the work-around of having two different (non-shared) listeners is acceptable.
14:14:49 <dougwig> right, but if i'm defining policies on two different subnets, i usually expect to define two network configs, even if i'm duping them.
14:15:07 <samuelbercovici> sbalukoff: it is as exceptable as using two different listeners for ipv4 amd ipv6
14:15:08 <Youcef> sbalukoff: agree, having 2 listeners is not a big deal.
14:15:45 <sbalukoff> samuelbercovici: Except that I'm saying the IPv4 + IPv6 for the same "service" or "listener" is a far more common scenario. :P
14:16:02 <samuelbercovici> sbalukoff: not in the use cases i have encountered
14:16:04 <Youcef> vivek-ebay: We can have ipv4+ipv6 with 2 different listeners (duplicate the listener), right?
14:16:08 <blogan> what it really comes down to is making it easier for an end user
14:16:16 <vivek-ebay> Youcef: right
14:16:32 <sbalukoff> blogan: Exactly.
14:16:41 <xgerman_> easier - could also mena more consistent which could mean two listeners
14:16:49 <samuelbercovici> so if it is the same application (listener and bellow) it should be defined once
14:16:52 <sbalukoff> Having two different non-shared listeners is not a show stopper. It's just less convenient for the user.
14:16:59 <aburaschi> I see the point of sharing a listener. Nevertheless, what if we only have a 2:N relationship, beeing only an IPv4/6 issue?
14:17:31 <xgerman_> I don't like creating special cases in an API --
14:17:32 <samuelbercovici> aburaschi: what about the use case, I have described? it can be more than 2...
14:17:42 <samuelbercovici> xgerman_:+1
14:17:50 <dougwig> it's also a question of where it's easier.  a UI can hide this.  but the api can require separate building blocks, as per xgerman_'s point.
14:18:15 <blogan> is keeping the user from having to do duplicate work and maintaining more than one listener/pool important enough to keep M:N?
14:18:25 <vivek-ebay> how much implementation complexity we see if we go with N:M route ?
14:18:37 <aburaschi> samuelbercovici, sure :)  Not trying to ignore the use case. Just trying to understand if a dual IPv4/6 interface is an option instead of an M:N relationship.
14:18:42 <enikanorov_> folks, i think that complexity of ipv4+ipv6 implemented with two LBs is solvable by proper UI
14:18:46 <sbalukoff> It's quite a bit more complex to implement N:M
14:18:54 <enikanorov_> and then we may want to go for more flexible N:M
14:18:57 <xgerman_> testing is a big hassle
14:18:57 <dougwig> vivek-ebay: there was a thread on the mailing list a few days ago that outlined some warts it'd bring to the drivers.
14:19:16 <sbalukoff> dougwig brought up some very good points about inconsistencies that can creep up with N:M, especially if N is a large number. :)
14:19:18 <jorgem> vivek-ebay: This should be just API. Implementation can be the same either way I would think right?
14:19:30 <samuelbercovici> enikanorov_: the key chalenge is with proviosning status and operation status on child objects
14:19:43 <samuelbercovici> we already going to face this with pools
14:20:09 <enikanorov_> samuelbercovici: that's the whole other big story... I wouldn't even try to address that within this bp
14:20:16 <sbalukoff> In any case, I'm willing to go with 1:M with no plans to go with N:M in the future...  any user asking for IPv6 is likely to be slightly more advanced anyway. :)
14:20:33 <xgerman_> +1 abd might have automation
14:20:54 <sballe_> sbalukoff: I like this appraoch since it will keep it simpler
14:20:57 <dougwig> sbalukoff: +1
14:21:10 <blogan> sbalukoff: I just don't want to go with 1:M adn add the IPv4 and IPv6 attributes and then go to N:M and make the IPv6 attribute unnecessary
14:21:25 <sbalukoff> blogan: Good point.
14:21:32 <aburaschi> +1 to blogan point
14:21:50 <sbalukoff> I don't think N:M is good from an implementation perspective (*any* implementation) for reasons that dougwig pointed out on the mailing list.
14:21:55 <samuelbercovici> can anyone specify, why M:N is an issue from an end user?
14:22:14 <enikanorov_> samuelbercovici: i think with a proper UI it's not an issue
14:22:18 <blogan> samuelbercovici: i think its good from an end user standpoint
14:22:26 <vivek-ebay> M:N should make it easier for end-user....i think its more of a implementation complexity issue
14:22:39 <aburaschi> agree
14:22:45 <sbalukoff> Implementation complexity versus user convenience.
14:22:48 <jorgem> I see either GUI users or API users (which hopefully means programatic interaction). If GUI then the issue can be abstracted. If programatic user it means righting slightly more code. I think 1:N is easier to understand and implement then with these assumptions.
14:22:57 <blogan> enikanorov_: that is true as well but I don't see how a UI will be able to maintain two different listeners that shoudl be the same
14:22:59 <Youcef> vivek-ebay: I think M:N is confusing for the user, but this is a matter of opinion :)
14:23:01 <sbalukoff> In this case, people are saying the implementation complexity is too great for not much user convenience.
14:23:02 <jorgem> writing*
14:23:28 <enikanorov_> blogan: not sure i understand. N:M means sharing listeners between LBs
14:23:32 <xgerman_> sbalukoff +1
14:23:53 <blogan> enikanorov_: oh i thought you were saying 1:N would be made simpler to do through the UI
14:23:55 <samuelbercovici> so are we in agrrement that M:n is the better approach from a user perspective?
14:23:58 <vivek-ebay> con someone briefly explain implementation complexity with M:N ? briefly
14:24:30 <blogan> vivek-ebay: dougwig sent an email about some of them on the ML
14:24:41 <blogan> vivek-ebay: on Tuesday I think
14:24:48 <dougwig> briefly:  "I don't have a strong objection, just an implementation shudder.  Of the
14:24:48 <dougwig> two backends that I'm familiar with, they support 1:N, not N:N  So, we
14:24:48 <dougwig> fake it by duping listeners on the fly. But, consider the extreme, say
14:24:48 <dougwig> 1000 LB's and 1 shared listener.  How long does it take to create 1000
14:24:48 <dougwig> listeners?  What happens when it fails on 998?  Ok, we rollback.  What
14:24:48 <dougwig> happens when the rollback fails?  Inconsistent state.  Driver's can't
14:24:48 <dougwig> async.  Driver's can't run cleanup routines later.
14:24:49 <dougwig> What about when half the LB's have lit listeners and the other half don't;
14:24:49 <dougwig> does the db say that N:N link is there yet or not?
14:24:50 <dougwig> Shrink the allowed number of listeners and the window of pain gets
14:24:50 <dougwig> smaller, but at operator scale, even a small window will get hit."
14:25:33 <vivek-ebay> so that supports N:M
14:25:50 <enikanorov_> dougwig: we do it per object. what does mean 'create 1000 listeners'?
14:25:55 <sbalukoff> vivek-ebay: Actually that says N:M leads to the above scenario, which is not good.
14:25:58 <aburaschi> Yes... I thought the whole point of LB was the other way round...
14:26:03 <enikanorov_> you create listener and associate it to LB
14:26:18 <enikanorov_> it either fails or succeeds for each association
14:26:21 <vivek-ebay> N:M would mean shared listner, which means we will have 1 instaed of 1000
14:26:27 <dougwig> enikanorov_: if you have 1000 LB's that share one listener, and a backend that doesn't support M:N, then you have to create 1000 listeners as an "atomic" operation.
14:26:35 <sbalukoff> Sure, but what if you've got a listener that is already shared to 1000 LBs, and make a change to the listener?
14:26:42 <sbalukoff> Or one of the sub-objects.
14:26:52 <sbalukoff> Same scenario applies that dougwig is describing.
14:26:53 <blogan> vivek-ebay: but on the backend there will most likely be 1000, depending on how the backend implements it
14:26:53 <vivek-ebay> oh ok....you meant from driver perspective.
14:27:16 <sbalukoff> vivek-ebay: Yes, I think so.
14:27:34 <samuelbercovici> guys, we have very similar issue with pools
14:27:39 <enikanorov_> i'd like to see a user that creates 1000 lbs that share the same listeners :)
14:27:48 <aburaschi> me too
14:27:51 <blogan> samuelbercovici: yes we do :(
14:28:01 <samuelbercovici> so this needs to be solved anyway
14:28:03 <enikanorov_> he probably pays big money to not to create listeners for each of his lbs :)
14:28:37 <samuelbercovici> btw. is is also the case with current implementation of healthmonitors
14:28:38 <blogan> can we not just start with with 1:M and add the N:M later if it is really needed?
14:28:45 <enikanorov_> anyway, N:M is definitely more code then 1:N
14:28:57 <sballe_> blogan: +1
14:28:58 <blogan> enikanorov_: +1
14:29:01 <enikanorov_> blogan: that would be significant API change
14:29:09 <dougwig> the 1000 is just to make the problem obvious.  it's still there with 2, it'll just be hit less often.
14:29:14 <samuelbercovici> enikanorov_: correct
14:29:35 <samuelbercovici> we are already going to do a significant change, so we might as well try to do the critical changes at onec
14:29:51 <aburaschi> +1 samuelbercovici
14:29:56 <blogan> enikanorov_: i know and thats the problem with it
14:29:58 <rm_work> not having strong feelings either way, my concern would be "is N:M feasible for Juno", more than anything else...
14:30:08 <samuelbercovici> this is why we either do 1:N "forever" or do M:N
14:30:16 <jorgem> It seems to me that sharing config is a nice concept but the real reason people want to "share" is because they can't copy configs. So copying seems to be the goal not necessarily sharing. Sharing across 1000 lbs sounds nice but what happens when you want to start making changes across these lbs and realize you didn't want to share afterall?
14:30:48 <jorgem> Its the same concept as side effects in coding
14:30:53 <enikanorov_> jorgem: you disassociate and create different listeners
14:31:02 <jorgem> correct which is a pain
14:31:11 <Youcef> jorgem: +1
14:31:12 <jorgem> just like refactoring code with side effects
14:31:19 <aburaschi> But you would have to do it anyway with 1:N
14:31:36 <jorgem> aburaschi: How so? It wouldn't be shared?
14:31:51 <enikanorov_> i don't see why is it a pain, that would depend on UI
14:32:02 <aburaschi> I mean, you would have to create all the relations from scratch
14:32:03 <enikanorov_> doing everything manualy via CLI is pain anyway
14:32:05 <samuelbercovici> but if is is realy the same application, than managing M differetn replicas specificaly in TLS and L7 become very inconvinient
14:32:06 <xgerman_> if we use UI we can also use 1:N
14:32:17 <enikanorov_> samuelbercovici: agree
14:32:27 <jorgem> enikanorov: My point is how much extra work is it really for a GUI or programatic API user to "copy" configs?
14:32:34 <blogan> samuelbercovici: another good point for having M:N
14:32:50 <samuelbercovici> jorgem: copy only address intiali deploy
14:33:10 <samuelbercovici> the key issues is the on-going operation aspects of it
14:33:25 <sbalukoff> samuelbercovici: That's actually a really good point.
14:33:40 <blogan> so dougwig has voiced his problems with M:N, are there any others?
14:33:52 <xgerman_> tetsing becomes difficult
14:33:57 <samuelbercovici> now, the minute that we share pools, we have already made a dive to managing such cases
14:34:50 <dougwig> the l7 point is a good one.  i'm not so fond of the "we're already in pain elsewhere" reasoning.  :)
14:34:51 <blogan> samuelbercovici: which is why I'd say we go with M:N or 1:N on both
14:35:05 <xgerman_> 1:N all the way :-)
14:35:33 <sbalukoff> blogan: 1:N on listeners:pools basically breaks L7 entirely, doesn't it?
14:35:41 <sbalukoff> Or are you suggesting creating duplicate pools?
14:35:55 <blogan> sbalukoff: yep
14:36:02 <samuelbercovici> for example, in M:N if you need tu update the default TLS certificate for the application, you do it once, if you replicate you do M times
14:36:26 <samuelbercovici> sbalukoff: why?
14:36:44 <sbalukoff> So, it's really about shifting the complexity of "interesting deployment failure scenarios" back to the user to deal with
14:36:48 <samuelbercovici> oh, you mean not shring pools?
14:37:11 <sbalukoff> samuelbercovici: Yes, that's what I meant.
14:37:31 <blogan> So you're advocating for sharing of pools?
14:37:32 <samuelbercovici> sbalukoff: well this becomes even more problematic
14:37:40 <blogan> because if we share pools, i don't know why we wouldn't share listeners
14:37:40 <rm_work> We are already 1:N on listener:pool? technically? because it's listener:l7policy:pool for the others
14:37:53 <sbalukoff> blogan: Good point.
14:38:31 <sbalukoff> rm_work: We're N:M because a given pool can be the target of many L7policies.
14:38:32 <enikanorov_> rm_work: i think it's N:M, because different listeners may use sam pool
14:38:35 <enikanorov_> *same
14:38:53 <sbalukoff> And yes, because different listeners can use the same default_pool_id.
14:39:01 <samuelbercovici> <enikanorov_: sbalukoff: you are both right
14:40:14 <samuelbercovici> so if we need to handle shared pool provisoning status and operations status, a similar approach should be used for listeners
14:40:33 <samuelbercovici> and as far as I understand this is the key compleixty in the implementation
14:40:48 <vivek-ebay> N:M makes sense for listener to pool
14:40:54 <jorgem> I honestly think that unintended side effects by sharing configs is more important to a lb user due to the mission critical nature of a lb. I actually advocate not sharing anything. Again, a GUI and script can help me out in terms of setup and scale. I care that my lbs work and are isolated from human error.
14:40:54 <sbalukoff> So, not being able to share pools seems to me like a much bigger burden on the user and not being able to share listeners. But again, from the code-- we're having to deal with the same kind of complexity around failure scenarios in any case.
14:41:05 <enikanorov_> samuelbercovici: i'd say this implementation item should be postponed
14:41:06 <Youcef> vivek-ebay: agree.
14:41:16 <enikanorov_> at least it should not be a part of the first patch
14:41:22 <xgerman_> jorgem +1
14:41:26 <blogan> enikanorov_: agreed
14:41:56 <Youcef> I see the lb:listener relationship differently than the listern:pool relationships. the latter is much more common in N:M.
14:42:05 <Youcef> *listener
14:42:15 <samuelbercovici> I care less about steps and more about what will be the delievry for Juno
14:42:21 <rm_work> yeah but i guess I don't count listener:l7policy:pool as M:N listener:pool, since l7policies aren't shared… so it's M:1 listener:pool, and 1:N:1 listener:l7policy:pool, no?
14:42:29 <xgerman_> also we said pool is a logical construct and gets provisioned when a listener or lb gets created
14:42:45 <samuelbercovici> rm_work: why l7 policies not be shared?
14:42:49 <sballe_> samuelbercovici: +1
14:42:55 <rm_work> are they? i just thought they weren't
14:43:02 <rm_work> maybe I am remembering the model wrong
14:43:11 <samuelbercovici> rm_work: it is one of the options
14:43:25 <samuelbercovici> rm_work: but lets not add this in for now
14:43:28 <rm_work> kk
14:43:33 <blogan> i think if we start sharing everything complexity and unexpected side effects increases exponentially
14:43:41 <sbalukoff> samuel's L7 policy model allows for sharing of L7 policies. Mine doesn't.
14:43:42 <xgerman_> + 1
14:43:47 <enikanorov_> jorgem: N:M is superset of 1:M, so if cloud operator wants, it can then forbid sharing
14:43:49 <rm_work> ah, that'd explain it sbalukoff
14:44:09 <sballe_> meant +1 on the Juno delivery as mentioned by samuelbercovici
14:44:42 <samuelbercovici> The blue print should describe the delivery and then the steaps to get ther
14:44:51 <rm_work> I'd also +1 that (as i said earlier, Juno delivery is what matters most if we don't have strong opinions in either direction)
14:45:19 <dougwig> we've been talking for 45 minutes.  not usually a sign on not having strong opinions.
14:45:23 <dougwig> :)
14:45:25 <rm_work> heh
14:45:32 <xgerman_> we can vote?
14:45:42 <sbalukoff> dougwig: Not in this group. XD
14:45:42 <blogan> if delivery is what matters then doing 1:M at first with the intention on donig N:M later would make more sense since there is no consensus
14:45:46 <jorgem> enikanorov: I trying to force it because even as a developer I still have bugs when dealing with "pass by reference" objects and such even though I am aware of these things. Again lbs are missions critical, I want to help humanity from shooting itself in the foot :)
14:46:31 <jorgem> If lbs weren't mission critical I would be indifferent
14:46:37 <enikanorov_> jorgem: agree, but that's phylosophy. In C++ you can use const&
14:46:38 <xgerman_> yeah, and I can see the support calls from users chnaging something and not realizing they broke all their lbs
14:46:50 <dougwig> would we be voting on B:L:P or 1:L:P or 1:L:1 ?  or just two of those?
14:46:50 <samuelbercovici> jorgem: if someone don't want to share than he might as well not share
14:46:51 <crc32> +1 jorgem at this point I don't want to see breaking one loadbalancer breal all the others.
14:46:54 <enikanorov_> so you may shoot or you may be safe from that
14:46:58 <enikanorov_> that's flexibility
14:46:59 <samuelbercovici> deciding on 1:N makes shring impossible
14:47:18 <JulianCash_> Vote = good.  Before the meeting ends = even better.
14:47:19 <rm_work> xgerman_ / dougwig: I'm afraid just voting might alienate people with valid opinions :( but i guess at some point it might be necessary?
14:47:28 <jorgem> enikanorov: I suppose. Your point makes sense it is just a preference then.
14:47:40 <crc32> enikonarov_: The point with const & is to avoid shoving the whole object on the call stack while still preserving the const.
14:47:58 <xgerman_> aren't we coding in Python?
14:48:09 <jorgem> enikanorov: I guess I can tell our GUI programmers to not share configs so I guess I'm fine then.
14:48:12 <blogan> alirght we're getting in the weeds
14:48:13 <enikanorov_> xgerman_: when someone says' shooting in the leg' ...
14:48:20 <samuelbercovici> so snake-biting in out foor :-)
14:48:30 <jorgem> xgerman_: I was using it as sort of metaphor lol
14:48:31 <rm_work> i think const& was a similie/metaphor/allegory
14:48:33 <blogan> so should there eb a vote and that vote is the final decision?
14:48:56 <rm_work> would the vote need to be a supermajority? >_>
14:49:01 <xgerman_> we need some mechanism of coming to a decision
14:49:23 <enikanorov_> i see more reasons for N:M
14:49:24 <sballe_> xgerman_: +1
14:49:28 <jorgem> flexibility is fine. We can control side effects via our GUI at Rackspace and tell API users to be careful.
14:49:37 <enikanorov_> jorgem: yep
14:49:39 <samuelbercovici> blogan: so taking odd the implementation complexity, you think that M:N should not be implemented
14:49:41 <samuelbercovici> ?
14:50:00 <rm_work> we can "straw poll" if that's less contentious maybe?
14:50:00 <samuelbercovici> odd==off
14:50:16 <xgerman_> well, if we want to hide ot from users, it's hard to implement, ...
14:50:21 <blogan> samuelbercovici: I'm leaning towards N:M but not strongly against either one.  I think the flexbility is most important, but I am afraid of the complexity caused by sharing everything
14:50:49 <samuelbercovici> I think we need to evalute the implementation complexity off-line
14:50:54 <aburaschi> I totally agree with blogan...
14:51:18 <aburaschi> and with you too, samuelbercovici.
14:51:19 <dougwig> my biggest concern is not making things late or brittle for Juno, frankly.
14:51:22 <samuelbercovici> are we in agreement that from a user-perspective M:N is the correct approach?
14:51:43 <sballe_> I agree we need to make this available in Juno
14:51:49 <xgerman_> I think the copy approach is easieer to understand
14:52:00 <rm_work> blogan / samuelbercovici / dougwig / sballe_ +1
14:52:08 <sbalukoff> samuelbercovici: It's certainly the simpler approach for the users and provides the most flexibility.
14:52:20 <jorgem> N:M is fine ~+1 :)
14:52:27 <aburaschi> I think we agree that M:N is the most flexible approach, and that there is some concern about getting that to work for Juno
14:52:29 <sbalukoff> jorgem: LOL!
14:52:42 <enikanorov_> i think we need to do what is right, even just N:M is not the whole completed refactoring
14:52:44 <samuelbercovici> so lets, give it a hsot, to pinpoint the key chalenges in doing it and evaluete complexity so we have abetter measured way to decide
14:53:11 <vivek-ebay> N:M for listener-to-pool +1
14:53:16 <blogan> okay so back to N:M then?
14:53:26 <JulianCash_> For me, even if there isn't a "final decision", a sense of how many people want what, and how strongly they feel would be nice before this ends in 7 min.  How can we quickly make a kinda vote thing happen.
14:53:28 <JulianCash_> ?
14:53:28 <rm_work> sounds like it
14:53:32 <sbalukoff> blogan: More or less.
14:53:41 <sbalukoff> We're all sort of luke-warm about it.
14:53:44 <sbalukoff> it seems.
14:53:49 <Youcef> N:M for listener to pool +1, N:M for lb:listener: -1  :)
14:53:56 <dougwig> i'm still 1:N, but not enough to really register a negative vote about it.
14:53:57 <blogan> I still think going with 1:M to start woudl be better, even though it is a major change later
14:54:12 <xgerman_> I like 1:M more
14:54:20 <sballe_> me too +1
14:54:22 <samuelbercovici> +1 for both
14:54:29 <rm_work> I like M:N but worry about Juno release
14:54:34 <sballe_> samuelbercovici: Not fair ;-)
14:54:43 <blogan> i like sam's idea of figuring out the implemenation issues offline
14:54:53 <sbalukoff> blogan: +1
14:55:04 <dougwig> blogan / samuelbercovici +1 on scoping
14:55:18 <rm_work> yeah, we don't have time in the next 5 minutes for a code review :P
14:55:20 <blogan> dare we try to move on to another topic?
14:55:30 <xgerman_> sure, we have 5
14:55:34 <samuelbercovici> so decision? give it till next week to quantify the effort and then get final decision?
14:55:41 <enikanorov_> blogan: i think we covered most of them
14:55:42 <xgerman_> yep
14:55:45 <rm_work> samuelbercovici +1
14:55:46 <blogan> samuelbercovici: sounds like it to me
14:55:47 <enikanorov_> except for status of the pool
14:55:50 <dougwig> where is the offline meeting?  who is taking point on that?
14:55:55 <jorgem> What about Epic/Umbrella?
14:55:57 <blogan> enikanorov: health monitor as well
14:56:04 <jorgem> thats on the agenda
14:56:13 <dougwig> any chance of getting an object model bp for l7/ssl, so we can evaluate the N:M in that context better?
14:56:21 <enikanorov_> blogan: IMO this also better postponed
14:56:26 <sballe_> I need to drop off. will read the scrollback later. Bye.
14:56:53 <blogan> enikanorov: thats fine, I think this is a good stopping point anyway
14:57:10 <jorgem> action items?
14:57:26 <blogan> research scope of implementation issues with N:M
14:57:36 <jorgem> #action research scope of implementation issues with N:M
14:57:39 <samuelbercovici> sam to send to ML intial bultes of things to address in M:n
14:57:51 <aburaschi> space to do that? ML?
14:57:58 <samuelbercovici> ML
14:58:01 <jorgem> aburaschi: yes
14:58:05 <aburaschi> ok, that was a late Enter...
14:58:08 <blogan> we can discuss some more in #neutron-lbaas as well
14:58:08 <aburaschi> :)
14:58:17 <xgerman_> #action sam to send to ML intial bultes of things to address in M:n
14:58:17 <Youcef> #action research scope of implementation issues with N:M for both lb:listener and listener:pool relationships
14:58:18 <sbalukoff> Yep.
14:58:31 <jorgem> blogan: true but it would be nice if discussions get paraphrased on ML as well
14:58:31 <sbalukoff> I'd like to see a bot get added to #neutron-lbaas
14:58:44 <sbalukoff> So that people have a place to look at conversations who can't be online all the time.
14:58:51 <jorgem> sbalukoff: yup
14:58:56 <aburaschi> +
14:58:58 <aburaschi> +
14:58:58 <dougwig> can we add neutron-lbaas to eavesdrop?  who's the person to contact about that?
14:59:00 <xgerman_> +
14:59:00 <aburaschi> +1
14:59:18 <enikanorov_> i don't know, may be mestery knows
14:59:18 <VijayB_> blogan: guess we're short on time to discuss the service implementation, so we can go back to the ML for that
14:59:21 <Youcef> =1
14:59:22 <JulianCash_> +
14:59:29 <Youcef> +1
14:59:34 <blogan> VijayB_: join #neutron-lbaas
14:59:38 <jorgem> i++
14:59:48 <VijayB_> blogan: ok
14:59:49 <sbalukoff> Haha
14:59:50 <rm_work> +1
14:59:51 <enikanorov_> ok, we're out of time
14:59:54 <sbalukoff> Ok, thanks y'all!
14:59:58 <xgerman_> thanks
14:59:58 <dougwig> bye
14:59:59 <enikanorov_> thanks everyone for joining
14:59:59 <aburaschi> Thank you all!
15:00:00 <jorgem> thanks!
15:00:05 <enikanorov_> #endmeeting