| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-23 | |||
| 15:47:45 | bauwser | instead of hijacking what we currently have, we should discuss on a better approach | |
| 15:47:55 | bauwser | which is what was johnthetubaguy exactly trying to do | |
| 15:48:39 | bauwser | johnthetubaguy: what is the new proposal, tbh I haven't gone thru all specs yet | |
| 15:49:00 | mriedem | i'm not following you | |
| 15:49:25 | mriedem | you can do hard anti affinity and fail if you can't place the VMs on separate hosts, | |
| 15:49:35 | mriedem | you can do soft anti affinity and get more VMs on a host than you'd really like | |
| 15:49:48 | mriedem | this is saying, i want soft but i can only tolerate up to a limit | |
| 15:49:56 | mriedem | or, soft is ok but to a limit | |
| 15:50:00 | dansmith | mriedem: I see it as a variant of hard not soft | |
| 15:50:08 | mriedem | sure, it's in between | |
| 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 | |