| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-23 | |||
| 15:37:12 | mriedem | is sgordon still a man about town? | |
| 15:37:18 | mriedem | isn't he in the UK/Ireland area? | |
| 15:37:40 | sgordon | mriedem, nah canadia | |
| 15:37:44 | mriedem | drats | |
| 15:37:52 | mriedem | sgordon: can you take a look at that spec regardless of your physical location? | |
| 15:38:09 | mriedem | gibi might also have some input here since ericsson added the soft affinity stuff | |
| 15:38:09 | sgordon | mriedem, yeah i just got the email notification and opened it up | |
| 15:39:14 | sgordon | mriedem, i have to admit i havent had anyone clamouring for this in a fair while, but that may just mean folks are working around it using host aggregates and higher level orchestration | |
| 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 | 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 | |