| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-23 | |||
| 15:31:10 | mriedem | since i've had this in my head the way it's proposed | |
| 15:31:21 | mriedem | dansmith: mention it in the spec? | |
| 15:31:36 | mriedem | either way i need to bring it up at the ptg b/c of some questions about how to model the thing in the api and db | |
| 15:32:21 | dansmith | I really hate the idea of adding extra_specs to anything, but especially groups | |
| 15:32:44 | mriedem | i said that on the spec | |
| 15:34:48 | dansmith | I guess their use-case actually specifically requires this as the model | |
| 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 | sgordon | mriedem, yeah i just got the email notification and opened it up | |
| 15:38:09 | mriedem | gibi might also have some input here since ericsson added the soft affinity stuff | |
| 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 | 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 | |