| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-10 | |||
| 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 | |
| 10:30:37 | gibi | but wait | |
| 10:30:46 | sean-k-mooney | hum | |
| 10:30:48 | sean-k-mooney | would they | |
| 10:30:50 | gibi | do we need to differentiate in the request spec object? not just in the request itself? | |
| 10:31:05 | sean-k-mooney | ya im thinking about that again | |
| 10:31:22 | sean-k-mooney | can we tell the difference between {availability=null} and the {} | |
| 10:31:52 | sean-k-mooney | the the reqested destination object that caries this i guess | |
| 10:32:00 | gibi | the request_spec contains None means no restriction. if the API request contains az=null that means reset what is in the request spec, if the API request contains {} then that means dont change the what is in the request_spec | |
| 10:32:22 | sean-k-mooney | gibi: ya that proably would work | |
| 10:32:32 | sean-k-mooney | ok maybe we can add that back | |
| 10:34:43 | opendevreview | Balazs Gibizer proposed openstack/nova stable/xena: Retry in CellDatabases fixture when global DB state changes https://review.opendev.org/c/openstack/nova/+/840949 | |
| 10:38:06 | sean-k-mooney | gibi: Uggla updated the etherpad hopefully that is now correct | |
| 10:38:46 | gibi | sean-k-mooney: yep it looks good to me | |
| 10:38:56 | gibi | thanks for trying out all the legacy cases I was sloppy | |
| 10:39:09 | sean-k-mooney | we dont have a way to pin an unpinned guest in this caes | |
| 10:39:19 | sean-k-mooney | unless you use the old microverion | |
| 10:39:41 | sean-k-mooney | is that an issue | |
| 10:41:46 | sean-k-mooney | im going to take a break form this spec for a while but ill come back to it after Uggla has updated it | |
| 10:43:32 | gibi | sean-k-mooney: I agree that pinnin is not possible now but I think that is OK | |
| 10:44:20 | gibi | I remember a lot more questions about unpinning than pinning in the past | |
| 10:44:43 | sean-k-mooney | ya we could always add it later if needed. i think we have enough to update the spec and then we can get bauzas's and dansmith's input to see if they agree | |
| 10:46:14 | gibi | I agree | |
| 11:53:19 | gibi | bauzas: left feedback in https://review.opendev.org/c/openstack/nova-specs/+/840217 | |
| 12:03:29 | gibi | bauzas: fyi I cannot attend the today's nova meeting | |
| 12:03:32 | gibi | I will read back | |