| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-10 | |||
| 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 | |
| 09:09:59 | bauzas | sean-k-mooney: maybe, I just feel we need to be super-explicit on what will happen to the instance | |
| 09:10:13 | sean-k-mooney | yes we do | |
| 09:10:36 | sean-k-mooney | its should be agreed in the spec. | |
| 09:10:44 | sean-k-mooney | so of the 3 options which is your preference | |
| 09:10:49 | bauzas | I turned to -1 unfortunately | |
| 09:11:03 | bauzas | sean-k-mooney: I like the KISS principle for our APIs | |
| 09:11:28 | bauzas | and I don't want us to do a lof of conditionals based on parameters values | |
| 09:11:28 | sean-k-mooney | bauzas: the shelve api is the supported way to move between AZs today | |
| 09:12:05 | bauzas | sean-k-mooney: I got your point, I just want us to agree on what would be the RequestSpec.AZ value once the unshelve is made | |
| 09:12:19 | sean-k-mooney | yep | |
| 09:12:30 | bauzas | sean-k-mooney: I was +2 on the fact we were breaking the AZ contract when unshelving | |
| 09:12:40 | sean-k-mooney | we had asked for that to be added to the spec in a previous revision | |
| 09:13:00 | bauzas | sean-k-mooney: I'm -1 on the fact we don't explain what will happen to the instance for the next move operations after the unshelve | |
| 09:13:15 | sean-k-mooney | bauzas: Uggla updated the spec but did not explcitly state it. there was a -1 form dansmith on this topic previously | |
| 09:14:30 | sean-k-mooney | bauzas: not i have not review th latest revision so i assume it is still missing if so then -1 is totally fair since this is still unadressed | |
| 09:17:13 | bauzas | sean-k-mooney: new revision only says the instance will be moved to the host, whatever the current AZ is. | |
| 09:17:30 | sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/831506/1..3/specs/zed/approved/unshelve-to-host.rst#b69= | |
| 09:17:40 | bauzas | but I guess Uggla didn't know the whole semantics of this RequestSpec.AZ field | |
| 09:17:41 | sean-k-mooney | bauzas: yep i revived the previous comment thread | |
| 09:18:29 | bauzas | sean-k-mooney: Uggla said the existing method unpins the AZ | |
| 09:18:53 | bauzas | leaving the instance freefloating | |
| 09:19:05 | sean-k-mooney | when you do unshelve --az az2 it sets requestspec.az to None? | |
| 09:19:10 | bauzas | no | |
| 09:19:21 | sean-k-mooney | oh when you do --host | |
| 09:19:24 | sean-k-mooney | it set it to noe | |
| 09:19:29 | sean-k-mooney | *None | |
| 09:19:39 | bauzas | yup | |
| 09:19:41 | bauzas | the latter | |
| 09:19:53 | sean-k-mooney | ya so that is not right in my view | |
| 09:19:57 | bauzas | for --az, we currently pin it to the target AZ AFAICR | |
| 09:20:09 | sean-k-mooney | its ok for the schduling request but the AZ should not get nuked in the request spec | |
| 09:20:12 | bauzas | but this is also debatable | |
| 09:20:36 | bauzas | unshelve --az shouldn't pin to the target AZ if the instance was formerly freefloating | |
| 09:20:45 | sean-k-mooney | correct | |
| 09:20:58 | sean-k-mooney | it should maintain the sematics it was booted with | |
| 09:21:04 | bauzas | yup | |
| 09:21:22 | sean-k-mooney | hence the "only update if it was not already None" mechanic | |
| 09:22:07 | bauzas | that's why I feel brave enough to tell we can be opinionated and imply that if an instance was pinned to an AZ and we unshelve to another AZ, we *should* pin this instance to that new AZ | |
| 09:22:52 | gibi | hm | |
| 09:22:54 | bauzas | and Gosh, customers who want the instance to freefloat after an unshelve... | |
| 09:22:59 | sean-k-mooney | bauzas: yes that is what i want to do doo | |
| 09:23:02 | sean-k-mooney | *too | |
| 09:23:09 | sean-k-mooney | if it was pinned before we pin to the new az | |
| 09:23:26 | gibi | I tried to collect my view: https://etherpad.opendev.org/p/RiWsCJFEI1LP80-niWho | |
| 09:23:45 | bauzas | sean-k-mooney: I just count the days before we would have a RFE saying 'I want to unpin my instance from any AZ" | |
| 09:24:57 | gibi | we could use the explicit AZ:none in the unshelve to trigger unpin | |
| 09:25:03 | gibi | if we want | |
| 09:25:49 | Uggla | gibi, +1 | |
| 09:26:10 | gibi | can we try to collect a similar table in the spec after we agreed on the semantic? | |
| 09:28:37 | gibi | awesome that you comment directly the etherpad it makes a lot easier to track the argument for different cases | |
| 09:29:17 | sean-k-mooney | bauzas: unshleve --AZ None :P | |
| 09:29:18 | bauzas | gibi: yep, we could profit from that microversion to allow AZ to be None | |
| 09:29:29 | sean-k-mooney | reject it if it does not contain the :P | |
| 09:29:34 | bauzas | (if we don't support it *yet*) | |
| 09:32:46 | bauzas | I'll have to disappear son | |
| 09:32:48 | bauzas | soon | |
| 09:33:04 | bauzas | but I captured my thoughts and I feel we're on the same page between gibi, sean-k-mooney and me | |
| 09:33:33 | gibi | yes I think so too | |
| 09:33:57 | gibi | lets figure out how the no AZ -> AZ case behaves today | |
| 09:34:02 | gibi | then we can settle the whole thing | |
| 09:35:59 | sean-k-mooney | i have a multi node devstack | |
| 09:36:09 | sean-k-mooney | ill quickly create some azs and boot some vms | |
| 09:36:10 | bauzas | me too but I have gym | |
| 09:38:01 | sean-k-mooney | ill update the etherpad | |
| 09:44:14 | gibi | I quickly checked if booted without AZ then unshelved to nova AZ then the RequestSpec was updated from null to nova | |
| 09:44:19 | bauzas | I like gibi's etherpad, short to read | |
| 09:44:38 | bauzas | gibi: :/ | |
| 09:56:01 | sean-k-mooney | gibi: just confirming my self but ok i guess we need to decied if we also want to change unshelve to az as part fo this micoverion | |
| 10:10:22 | sean-k-mooney | Uggla: so assuming we all agree that we should change the behavior for unshleve to az with no az in boot the request spec initally | |
| 10:10:38 | sean-k-mooney | can you add 2 tables to the spec | |
| 10:10:56 | sean-k-mooney | 1 with the existing behavior for all the cases in gibis etherpad and then a second with the new behaiovr | |
| 10:11:48 | Uggla | sean-k-mooney, yep based on the etherpad table it is clear. Of course I will change the specs with previous and new behavior. | |
| 10:13:48 | sean-k-mooney | i have copied it to my other etherpad and created the updated tables | |
| 10:13:55 | sean-k-mooney | https://etherpad.opendev.org/p/unshelve-to-host#L63 | |
| 10:14:13 | sean-k-mooney | gibi: ^ | |
| 10:19:02 | Uggla | sean-k-mooney, I think table is fine | |
| 10:22:02 | sean-k-mooney | actully there is a conflict | |
| 10:22:18 | sean-k-mooney | so we cant supprot unshlve to any az without a new paramater | |
| 10:26:36 | sean-k-mooney | ill just strick though those lines ot note that we can ignore it | |
| 10:26:41 | sean-k-mooney | if that works for you | |
| 10:28:26 | gibi | sean-k-mooney: so the conflict is that we cannot distinguish between {availability=null} and the {} request? | |
| 10:29:16 | sean-k-mooney | yes | |
| 10:29:32 | sean-k-mooney | well more how to store that delta in the python object | |
| 10:29:59 | sean-k-mooney | as in the request_spec used by the schduler | |
| 10:30:14 | sean-k-mooney | since both woudl have AZ=None | |
| 10:30:18 | gibi | ahh yes | |