Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-23
15:50:18 dansmith mriedem: it's the same filter has hard but instead of ==0, it's <=$max
15:50:27 dansmith you can't do this with a weigher is my point
15:50:30 johnthetubaguy dansmith: +1
15:50:36 dansmith and that's what soft anti-affinity is
15:50:47 mriedem a weigher is not being proposed
15:50:52 dansmith I know
15:50:56 bauwser mriedem: soft anti-affinity should never hard-stop
15:51:19 bauwser hard anti-affinity is something we already have
15:51:21 mriedem umm
15:51:29 dansmith mriedem: I'm saying this is proposing changing our hard filter from ==0 to <$max
15:51:30 mriedem so flacid anti affinity as a new policy?
15:51:40 bauwser what the proposer asks is a way to have a mechanism that would describe a 'max" limit
15:51:50 mriedem yes i understand
15:51:53 bauwser dansmith: and I don't like that
15:52:01 bauwser because it would confuse a lot of people
15:52:04 dansmith bauwser: neither do I, I think that's a confusing model
15:52:31 dansmith I would rather a policy of min-redundancy, with a value of the minimum
15:52:32 mriedem so your issue is creating a group with the soft policy but then having this attribute which makes it more hard than soft,
15:52:33 bauwser my point is, instead of trying to hack our current model, rather try to describe a better model
15:52:41 mriedem so it's a conception issue
15:52:45 bauwser exactly
15:52:46 mriedem so a new policy
15:52:46 dansmith mriedem: but it wouldn't be that
15:52:55 dansmith mriedem: it would be hard with a grace limit
15:53:01 bauwser sometimes people want to hard-fail on a filter, but sometimes they prefer to soft-fail
15:53:17 dansmith bauwser: I'm not sure what that has to do here,
15:53:31 dansmith because this is still hard fail on this filter, it's just at a nonzero level of duplication
15:53:42 mriedem ok, so create a server group with the anti-affinity policy (hard) with some limit on overlap
15:53:42 dansmith if you go over that limit, which is currently zero, you hard fail all the time
15:53:45 dansmith with what is proposed here
15:54:00 dansmith mriedem: that's what is being proposed here
15:54:08 mriedem no it's not, it's the opposite
15:54:14 mriedem the spec is talking about the soft policy
15:54:18 mriedem you're saying soft policy is bad optics,
15:54:24 mriedem so flip it to be hard policy,
15:54:28 mriedem with the overlap limit
15:54:39 mriedem either way we get to the same thing
15:54:40 dansmith mriedem: but the spec is wrong in how things work
15:54:42 leakypipes did someone say flaccid affinity?
15:54:49 dansmith mriedem: they think they're adding a limit to soft, but you can't do that
15:54:49 mriedem leakypipes: yes, word of the day
15:55:01 dansmith you can increase the limit on hard though
15:55:04 mriedem dansmith: b/c soft is enforced via weigher
15:55:07 mriedem sure,
15:55:10 dansmith mriedem: exactly
15:55:11 mriedem so yeah let's make that point in the spec
15:55:19 bauwser I'm just commenting it
15:55:46 bauwser dansmith: are you proposing to have a max limit defined on the filter ? I don't like that
15:56:17 dansmith bauwser: no, I'm saying that is what they are proposing here
15:56:19 dansmith they just don't know it
15:56:19 jroll (disclaimer, haven't read the spec) so, use case: I want to be able to say "I want 20 instances spread across at least 5 hosts, but preferably across more" - I think that's what is proposed here (based on this conversation), is that correct?
15:56:34 dansmith jroll: no, that's what I was saying though
15:56:39 dansmith that's what I would prefer I mean
15:56:55 jroll dansmith: and this is what the spec thinks it is proposing, but it's really not? :)
15:56:57 bauwser jroll: that's exactly what weighers aim to achieve
15:57:11 bauwser for that usecase
15:57:11 dansmith jroll: no, that's not what the spec thinks its proposing
15:57:22 mriedem jroll: dansmith: well one thing is when you create the group, you don't say how many instances are going to be in it
15:57:26 bauwser ie. ponder your list of hosts based on some criterias that are given by weighers
15:57:35 dansmith jroll: it's proposing that you know how big the group will ever be, and set the allowed overlap per host to some number so you get the desired amount of minimum redundancy
15:57:37 mriedem so "I want 20 instances spread across at least 5 hosts" is a bit chicken and egg to me
15:57:41 dansmith which is much harder to reason about
15:57:54 jroll dansmith: ah, ok, will read again
15:57:55 mriedem but i guess if you already know when you create the group how many VMs are going to be in it, then that works
15:58:12 dansmith mriedem: that's what this spec requires, is you to know how many instances will be in there
15:58:46 dansmith mriedem: but, if you say "I want minimum redundancy of three" then you don't get any overlap until you boot the fourth and now you can start to double up because you've achieved that minimum level
16:00:23 leakypipes dansmith: I think you saw the use case section begin with "As a NFV user, ..." and immediately threw up in your mouth ;)
16:00:25 bauwser dansmith: it's very different
16:00:47 bauwser dansmith: but I agree, describing for anti-affinity how many groups you want is somehow reasonable
16:00:49 jroll leakypipes: there's vomit everywhere in here from that
16:00:54 leakypipes :)
16:01:18 dansmith bauwser: how many groups? you lost me there :)
16:01:31 mriedem i think he means group of VMs per host in the group?
16:01:32 bauwser man
16:01:40 bauwser mriedem: bonus point
16:01:44 dansmith oh min-redundancy you mean?
16:01:54 jroll dansmith: I read through it, I agree with what you're suggesting there, thanks
16:01:59 dansmith I think that's how most people will want to define a thing like this
16:02:08 dansmith and jroll does, so.. end of story
16:02:11 bauwser call it failure zone
16:02:34 bauwser but if we call it failure zone, then leakypipes would kill me
16:02:40 bauwser and I'm scared
16:02:46 leakypipes bauwser: indeed I would.
16:03:15 bauwser why people are doing instance groups besides the idea that they expect groups of failure domains
16:03:16 bauwser ?
16:03:49 bauwser leakypipes: you don't imagine my mood now... restating https://www.thelocal.fr/20180223/french-cheese-wars-are-the-days-of-the-real-normandy-camembert-numbered
16:03:52 leakypipes bauwser: because... N. F. V.
16:04:06 leakypipes hahaha
16:04:20 leakypipes that's awesome.
16:04:41 leakypipes only in La France
16:08:51 leakypipes mriedem: did you say that https://review.openstack.org/#/c/546925/2/specs/rocky/approved/allow-specifying-limit-for-affrinity-group.rst was somehow related to something sgordon put together?
16:09:15 mriedem see the bp
16:09:22 mriedem https://blueprints.launchpad.net/nova/+spec/complex-soft-anti-affinity-policies
16:09:32 leakypipes oh... 113355
16:10:00 leakypipes ok, not 113355
16:10:16 mriedem https://review.openstack.org/#/c/546925/
16:10:38 mriedem https://review.openstack.org/#/c/224325/ is the old backlog spec
16:10:44 leakypipes mriedem: yeah, was confused since the spec is called something different than the blueprint.
16:13:56 leakypipes mriedem: ftr, k8s does this very well.
16:14:07 leakypipes mriedem: because, you know, it's an *orchestrator*.

Earlier   Later