Earlier  
Posted Nick Remark
#openstack-nova - 2022-05-10
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
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 sean-k-mooney bauzas: the shelve api is the supported way to move between AZs today
09:11:28 bauzas and I don't want us to do a lof of conditionals based on parameters values
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

Earlier   Later