| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-23 | |||
| 15:43:44 | bauwser | mriedem: dansmith: we have a clear distinction between filters which hard-check possibilities and weighers which soft-check | |
| 15:44:15 | bauwser | having some middleground is something more than just for affinity | |
| 15:44:22 | bauwser | tbc, I'm -2 on the spexc | |
| 15:45:26 | bauwser | mriedem: dansmith: but johnthetubaguy had an idea to deprecate filters/weighers and have a different semantic for saying "here I want to hard-stop or fail-safe" | |
| 15:46:09 | johnthetubaguy | bauwser: got a pointer to the new one | |
| 15:46:22 | johnthetubaguy | might be better than my previous re-write the world plan | |
| 15:46:24 | dansmith | bauwser: this is harder than soft | |
| 15:46:38 | bauwser | soft is weighting | |
| 15:46:43 | bauwser | hard is filtering | |
| 15:46:54 | bauwser | here they want to have a soft-but-hard | |
| 15:46:57 | dansmith | bauwser: right, this spec specifies something hard, which is filtering, | |
| 15:47:08 | bauwser | bref | |
| 15:47:12 | dansmith | but it weakens the normally hard anti-affinity for some value of allowed overlap | |
| 15:47:16 | dansmith | I really don't like it | |
| 15:47:20 | bauwser | it's unclear and I don't think modifying filters or weighers is a good thing | |
| 15:47:26 | bauwser | yeah exactly that | |
| 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 | dansmith | mriedem: but it wouldn't be that | |
| 15:52:46 | mriedem | so a new policy | |
| 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 | dansmith | if you go over that limit, which is currently zero, you hard fail all the time | |
| 15:53:42 | mriedem | ok, so create a server group with the anti-affinity policy (hard) with some limit on overlap | |
| 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 | mriedem | leakypipes: yes, word of the day | |
| 15:54:49 | dansmith | mriedem: they think they're adding a limit to soft, but you can't do that | |
| 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 | 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:19 | dansmith | they just don't know it | |
| 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 | dansmith | jroll: no, that's not what the spec thinks its proposing | |
| 15:57:11 | bauwser | for that usecase | |
| 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 | |