| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-10 | |||
| 14:03:35 | bauzas | mriedem: no | |
| 14:03:38 | mriedem | i don't know what you mean by 2 hosts within that group | |
| 14:03:40 | gibi | bauzas: you cannot have an affinity group with two hosts iff you evacuated with --force | |
| 14:03:46 | bauzas | mriedem: same_host hint is for SameHostFilter | |
| 14:04:10 | gibi | bauzas: I mean can only have affinity group on two hosts iff you evacuated one of the VMs with --force | |
| 14:04:25 | bauzas | gibi: right, this is my point | |
| 14:04:36 | bauzas | gibi: so, say I end up with the group having 2 hosts | |
| 14:04:57 | bauzas | I guess it would be possible to migrate from one to another | |
| 14:05:13 | bauzas | also, I don't remember but I think we now have weighters right? | |
| 14:05:48 | gibi | bauzas: that means you have a broken group so I would not say anythin about what happens when you have a broken group. The precodition is not true so anything can happen | |
| 14:06:30 | gibi | bauzas: weighters for groups are to implement soft-affinity and soft-anti-affinity | |
| 14:06:55 | bauzas | oh right | |
| 14:07:01 | bauzas | seriously | |
| 14:07:14 | bauzas | Affinity and AntiAffinity are very strict policies | |
| 14:07:19 | gibi | yes | |
| 14:07:26 | mriedem | yeah i was thinking of ServerGroupAffinityFilter | |
| 14:07:31 | mriedem | i create a group with policy 'affinity' | |
| 14:07:36 | mriedem | create 3 servers in that group | |
| 14:07:40 | mriedem | i expect them to be on the same host | |
| 14:07:43 | mriedem | so i can't migrate them | |
| 14:07:45 | bauzas | mriedem: you're correct | |
| 14:07:47 | mriedem | b/c that would violate the policy | |
| 14:07:50 | gibi | correct | |
| 14:07:53 | mriedem | ok | |
| 14:08:01 | bauzas | mriedem: yup, but you can disable the filter if you need so | |
| 14:08:02 | mriedem | so we should document that in the api | |
| 14:08:09 | mriedem | bauzas: the operator can | |
| 14:08:09 | bauzas | well, it's a policy | |
| 14:08:10 | mriedem | the user can't | |
| 14:08:29 | bauzas | mriedem: sure, but the hint is transparent | |
| 14:08:38 | bauzas | I mean | |
| 14:08:45 | bauzas | it's self-explanatory | |
| 14:09:09 | bauzas | FWIW, it can even be a DoS vector... | |
| 14:09:13 | bauzas | like | |
| 14:09:25 | bauzas | of course we have quotas tho | |
| 14:09:42 | bauzas | but as a user, I can inflect which host my instances will end up | |
| 14:09:56 | bauzas | FWIW, I do much prefer the soft policies | |
| 14:10:41 | gibi | but soft mean nova promises nothing about the placement | |
| 14:10:54 | gibi | a soft affinity group with 10 instances on 10 different host is valid | |
| 14:11:18 | gibi | but most probably not what the user wanted | |
| 14:11:42 | gibi | so for me both affinity and soft-affinity have its use case | |
| 14:12:30 | mriedem | affinity is just for performance right? | |
| 14:12:34 | gibi | we could define the level of softness in the soft-affinity technically (e.g. how many violations are allowed) but that is extra complexity | |
| 14:12:41 | mriedem | i want my web server and db server on the same host | |
| 14:13:13 | gibi | mriedem: yes that is the use case in my head for affinity | |
| 14:13:21 | jaypipes | gibi: yeah, way too much complexity in my opinoin... | |
| 14:13:55 | mriedem | bauzas: gibi: i think it's still worth documenting in the api-ref that you can't migrate affined instances | |
| 14:14:06 | mriedem | users could think that we migrate the entire group | |
| 14:14:10 | mriedem | which we don't | |
| 14:14:43 | bauzas | gibi: I wouldn't play with affinity if I was a blind user honestly | |
| 14:15:12 | bauzas | gibi: I'd rather find a public cloud provider that would guarantee me some space with no noisy neighbors | |
| 14:15:52 | bauzas | gibi: affinity and anti-affinity policies are for super users that have kind of knowledge of what the cloud has in its guts IMO | |
| 14:16:03 | gibi | in a public cloud I would do that you suggest. In a private telco cloud I might use affinity and anti-affinity | |
| 14:16:21 | bauzas | that's my point | |
| 14:16:33 | bauzas | if I'm private cloud, I have a team to bog with | |
| 14:16:38 | bauzas | to bug* | |
| 14:16:55 | bauzas | like, I want to spin X instances and I want the maximum IO | |
| 14:17:00 | bauzas | that's a good thing | |
| 14:17:46 | gibi | yes | |
| 14:17:50 | gibi | I think we agree | |
| 14:17:54 | bauzas | but then, you'll end-up with such locked-in environment that you'll need the help of your SA team to move your instances or you kill'em all | |
| 14:18:35 | mriedem | well, when gibi implements migration of entire server groups, then this won't be a problem anymore | |
| 14:19:04 | gibi | migration of an entire group is something I like as an idea | |
| 14:19:22 | gibi | but it might needs a scheduler that considers more than one instances at a time | |
| 14:19:31 | gibi | or I have to order the instances properly | |
| 14:20:39 | gibi | so I feel a bit frightened to jump into that implementation right now | |
| 14:23:24 | gibi | also if we talk about server groups then one big limitation of the group approach over the same_host / different_host approach is that a instance can only be part of a single group today | |
| 14:23:42 | gibi | while the hints are allowing a lot more complex setup than tat | |
| 14:23:43 | gibi | that | |
| 14:24:41 | gibi | of course it is just a technical limitation today | |
| 14:25:06 | bauzas | mriedem: migrating a server group as a whole is kinda of a big deal with the current implementation | |
| 14:25:27 | bauzas | even not talking of claims | |
| 14:25:48 | bauzas | but what if for example, a user is booting yet another instance for that group while we migrate ? | |
| 14:26:10 | bauzas | or, how can we be sure some target has enough resources by the time we migrate ? | |
| 14:26:14 | mriedem | bauzas: we don't allow adding/removing members for a group right? | |
| 14:26:34 | bauzas | mriedem: removing, no | |
| 14:26:46 | bauzas | mriedem: adding, it's like the single usecase we implemented | |
| 14:26:56 | gibi | adding a new instance not adding an existing one | |
| 14:27:08 | bauzas | yup, that | |
| 14:27:20 | gibi | but I agree with bauzas here | |
| 14:27:38 | gibi | this is complex | |
| 14:27:54 | mriedem | you guys realize i'm half joking about saying once gibi implements migrate server groups right? | |
| 14:28:08 | mriedem | i realize it's a giant mess today | |
| 14:28:43 | mriedem | i just like to set the insurmountable task | |
| 14:30:04 | mriedem | gibi: i'm creating a growth opportunity for you :) like a good first line manager. | |
| 14:30:35 | mriedem | gibi: oh btw, | |
| 14:30:49 | mriedem | did you see my comments on the instance tags in the versioned notifications patch? | |
| 14:30:56 | gibi | mriedem: honestly I grow in this community every day and I'm very happy about that | |
| 14:31:02 | mriedem | speaking of insurmountable tasks | |
| 14:31:42 | gibi | mriedem: I even responded to them ;) | |
| 14:31:54 | openstackgerrit | Simon Dodsley proposed openstack/nova-specs master: Enhanced KVM Storage QoS https://review.openstack.org/340168 | |
| 14:34:20 | openstackgerrit | Simon Dodsley proposed openstack/nova-specs master: Enhanced KVM Storage QoS https://review.openstack.org/340168 | |
| 14:35:08 | mriedem | djohnsto: got something for you https://bugs.launchpad.net/nova/+bug/1680773 | |
| 14:35:08 | openstack | Launchpad bug 1680773 in OpenStack Compute (nova) "Migration of a one VM deployed as part of group fails with NoValidHost" [Undecided,Incomplete] - Assigned to Arun Mani (arun-mani) | |
| 14:35:10 | mriedem | djohnsto: see the last comment | |
| 14:35:29 | mriedem | djohnsto: we could use a note in the docs about server groups with an affinity policy that they can't be migrated | |
| 14:35:42 | mriedem | djohnsto: that doesn't close the bug, so i'd push that as a Related-Bug change | |
| 14:43:34 | openstackgerrit | Simon Dodsley proposed openstack/nova-specs master: Enhanced KVM Storage QoS https://review.openstack.org/340168 | |
| 14:48:07 | openstackgerrit | Sean Dague proposed openstack/nova master: remove log translation tags from nova.cells https://review.openstack.org/454854 | |
| 14:49:37 | openstackgerrit | Simon Dodsley proposed openstack/nova-specs master: Enhanced KVM Storage QoS https://review.openstack.org/340168 | |