| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-10 | |||
| 08:33:04 | bauzas | now, I see why a lof of our customers prefer unshelve... | |
| 08:33:12 | bauzas | because of the open bug | |
| 08:33:37 | bauzas | I'm saying this is a bug, as this *shouldn't* | |
| 08:33:58 | bauzas | be possible to move an instance out of AZ1 if the user asked AZ1 when creating the instance | |
| 08:34:20 | bauzas | as a reminder, availability zones are seen by end users | |
| 08:35:38 | bauzas | Uggla: sean-k-mooney: for example, say I'm a enduser and I want to create an instance in some OVH SBG4 AZ :) | |
| 08:36:04 | bauzas | (where only hosts within the SBG4 datacenter are within this AZ) | |
| 08:36:23 | bauzas | then, I see some problems with SBG4 | |
| 08:36:41 | sean-k-mooney | bauzas: unshelve intentionally allwos you to chagne AZ | |
| 08:37:01 | bauzas | but magically, now I look at my instance and I see it in RBX1 | |
| 08:37:11 | bauzas | I wonder why | |
| 08:37:14 | sean-k-mooney | unshleve wont change az by default | |
| 08:37:27 | sean-k-mooney | it only change az if you specify an az | |
| 08:37:35 | bauzas | sean-k-mooney: I don't see why this is intentional | |
| 08:37:38 | bauzas | this is rather a bug | |
| 08:37:44 | sean-k-mooney | no its not | |
| 08:37:49 | sean-k-mooney | its deffinelty a feature | |
| 08:37:56 | bauzas | I strongly disagree | |
| 08:38:02 | bauzas | I know customers use it | |
| 08:38:05 | bauzas | because of this bug | |
| 08:38:19 | bauzas | but I dislike this behaviour because it tramples our endusers | |
| 08:38:21 | sean-k-mooney | unshelve is the only operation that is safe to use to move between azs | |
| 08:38:34 | sean-k-mooney | bauzas: rembere that unshelve is an end user operation not an admin one | |
| 08:38:38 | bauzas | unshelve was created by Rackspace | |
| 08:38:47 | sean-k-mooney | so its the same use that spefifed it on but and unshelve | |
| 08:38:56 | bauzas | correct | |
| 08:39:18 | bauzas | but originally we just offloaded resources with keeping quotas | |
| 08:39:21 | sean-k-mooney | so they know there constratits and are able to determin if they want to move between azs | |
| 08:39:26 | bauzas | as this was a public cloud need | |
| 08:39:45 | sean-k-mooney | bauzas: yes and then later we extended the api to add unshleve to AZ | |
| 08:39:46 | bauzas | as a public cloud, they wanted their endusers to keep their quotas | |
| 08:39:57 | bauzas | sean-k-mooney: that's when we confused things | |
| 08:40:22 | sean-k-mooney | we did it because operatores and customers wanted a way to move vms between regions/az | |
| 08:40:30 | bauzas | take the SBG and RBX datacenter examples | |
| 08:40:32 | sean-k-mooney | e.g. form dev to prod | |
| 08:40:53 | bauzas | sean-k-mooney: when we accepted this, we did put the users under the bus | |
| 08:40:59 | sean-k-mooney | no we dont | |
| 08:41:22 | sean-k-mooney | that woudl only be an issue if and only if we have cinder voluems and dont allow cross az attach | |
| 08:41:34 | sean-k-mooney | in which case it will fail to unshelve | |
| 08:41:38 | bauzas | we change what end users see | |
| 08:41:46 | sean-k-mooney | at there request | |
| 08:42:02 | bauzas | and we changed what they originally requested | |
| 08:42:02 | sean-k-mooney | its ok to change what az they see if they explictly ask you to change that | |
| 08:42:14 | sean-k-mooney | yes because they ask us too | |
| 08:42:28 | sean-k-mooney | for unshelve to host we have 3 options | |
| 08:42:44 | sean-k-mooney | 1 make it an error if the az of the host does not match the current az | |
| 08:43:05 | sean-k-mooney | 2 allow both az an host to be passed and ensure the host is in the az that is pass but allow the az to change | |
| 08:43:36 | sean-k-mooney | 3 accpet az or host mutlally exclusivly and implictly update the az if the host is in a different az | |
| 08:43:48 | sean-k-mooney | the spec currelty sates option 3 | |
| 08:44:04 | sean-k-mooney | gibi: ^ this is the az issue i mentioned yesterday by the way | |
| 08:44:50 | gibi | yepp, so I'm OK with option 3 | |
| 08:44:56 | sean-k-mooney | bauzas: all 3 of those behavior are valid i woudl argue that 1 is rather unfrendly ux 2 and 3 are actully my preference | |
| 08:45:33 | bauzas | sean-k-mooney: problem with option 3 is that we're changing the constraints | |
| 08:45:44 | bauzas | sean-k-mooney: correct me if I'm wrong | |
| 08:45:46 | bauzas | , | |
| 08:46:02 | bauzas | user created inst1 with 'sbg4' az | |
| 08:46:11 | bauzas | sbg4 went on fire | |
| 08:46:21 | bauzas | (or rather bad example | |
| 08:46:32 | bauzas | user shelved inst1 | |
| 08:47:04 | bauzas | now, op wants inst1 in hostB which is on rbx1 AZ | |
| 08:47:27 | bauzas | he will unshelve to hostB | |
| 08:47:40 | bauzas | inst1 will now have requestspec.az to be None | |
| 08:48:06 | bauzas | which means that inst1 could be later moved to any AZ, including rbx2 for example | |
| 08:48:36 | bauzas | that's the problem I see | |
| 08:50:07 | kashyap | Can anyone please post the output of this in a pastebin? | |
| 08:50:13 | kashyap | virsh domcapabilities | xmllint --xpath "//cpu/mode[@name='host-model']" - | |
| 08:50:14 | sean-k-mooney | bauzas: yep you miss understand what we are proposing | |
| 08:50:47 | kashyap | (I'm assuming your host is not a Leonov T470s) | |
| 08:50:53 | bauzas | sean-k-mooney: perhaps, I need to understand then more your point | |
| 08:50:55 | Uggla | bauzas, I think so as well. But specifying the az in a unshelve to host request spec may fix this problem but I have not tested it yet. | |
| 08:51:07 | sean-k-mooney | bauzas: when we change az the requestspec.az will be set to rbx1 if and only if the requestspec.az was previously not None | |
| 08:51:32 | bauzas | sean-k-mooney: then this is a breaking change too | |
| 08:51:50 | sean-k-mooney | bauzas: that what we do with unshleve pasing an az | |
| 08:51:51 | bauzas | sean-k-mooney: if ReqSpec.az was None before, instance was able to float across AZs | |
| 08:52:16 | sean-k-mooney | bauzas: right so we only upsate requestspec.az if it was not None | |
| 08:52:26 | gibi | kashyap: https://paste.opendev.org/show/bxPqOPQm7kvKqNhDcdp6/ | |
| 08:52:27 | bauzas | I'm confused | |
| 08:52:29 | sean-k-mooney | if its None we leave it none | |
| 08:52:58 | sean-k-mooney | bauzas: ok maybe we need a worked example in the spec. | |
| 08:53:08 | sean-k-mooney | let me create an etherpad quickly and add one | |
| 08:53:26 | bauzas | sean-k-mooney: there are only two cases we need to consider | |
| 08:53:35 | sean-k-mooney | https://etherpad.opendev.org/p/unshelve-to-host | |
| 08:53:37 | bauzas | 1/ reqspec.az was nonez | |
| 08:53:39 | kashyap | gibi: Thank you! (I'm curious, what is your host?) | |
| 08:53:47 | bauzas | 2/ reqspec.az != Nonz | |
| 08:54:14 | gibi | kashyap: https://paste.opendev.org/show/boLIfNJaksQMBL4ArQNs/ | |
| 08:54:20 | bauzas | for 1/, this is a simple scenario : instance can float, hence we don't care and we shouldn't change it | |
| 08:54:41 | bauzas | since the user didn't specific a AZ, we're free to pick any host | |
| 08:55:02 | bauzas | for 2/, reqspec.az = 'sbg4' for example | |
| 08:55:24 | bauzas | then, op transfers it to hostB which is 'rbx' | |
| 08:55:28 | bauzas | what assumtion should we do ? | |
| 08:56:09 | kashyap | gibi: Thanks :) | |
| 09:06:33 | bauzas | sean-k-mooney: I see you writing | |
| 09:06:39 | bauzas | :) | |
| 09:07:04 | bauzas | Uggla: don't be afraid, but we're possibly redesigning the whole API | |
| 09:07:37 | bauzas | sean-k-mooney: I like the idea to use the AZ parameter to specify whether you want the instance to stick with that AZ | |
| 09:07:58 | bauzas | sean-k-mooney: but I'm afraid this could be errorprone | |
| 09:08:11 | bauzas | this is about to be a confusing API | |
| 09:09:01 | sean-k-mooney | bauzas: so i think Uggla went with option 3 or case 2.3 to avoid that confusion | |
| 09:09:54 | sean-k-mooney | by makeing the az update we fulfile there request by moving the instance to the requested host and make the az consitnet if the vm was previously pinned | |