Earlier  
Posted Nick Remark
#openstack-nova - 2020-11-11
14:34:56 stephenfin I really wish we could use hyphens. 'server-resize confirm' makes way more sense to me
14:35:02 gibi dansmith: I would also not make a different config just to support all-in-one deployments
14:35:56 gibi stephenfin: we have openstack server resize --confirm but that is deprecated in favor of server resize confirm
14:36:14 dansmith gibi: definitely
14:37:00 dansmith gibi: if packages or deployment tools want to make something natively work if everything is on the same machine, separating things into config files and passing them on the command line is fine and well within their scope
14:37:03 stephenfin gibi: That was me. It makes more sense, IMO. The entire behavior of the command shouldn't change because of a boolean flag
14:37:11 stephenfin Like 'server show --diagnostics' :-(
14:37:24 owalsh dansmith: that's the plan IIUC
14:37:31 dansmith cool
14:37:35 dansmith now I can get coffee.
14:37:49 owalsh dansmith: but can't fail hard in nova-compute till that's done
14:38:13 gibi dansmith: so we might need to delay merging https://review.opendev.org/#/c/762176/ as it would break more than one deployment engine. As it seems debian also uses a shared nova.conf in the all-in-one-case
14:39:33 gibi stephenfin: I don't say that we should bring back --confirm
14:39:50 stephenfin oh, I know. I'm just explaining my rationale for that change
14:40:08 stephenfin i.e. don't hate me for it :-)
14:40:17 gibi stephenfin: is there a generic problem with this positional argment place used as subcommand name in general
14:40:25 gibi in osc?
14:40:33 dansmith gibi: okay, I'll throw my support on there for it and let you move it forward when appropriate
14:40:51 gibi dansmith: ack. I will summarize the whole thing in an ML post
14:41:04 gibi just to get more attention from the deployer engines
14:41:12 stephenfin gibi: Not really. I mean, if someone hit this corner case I think they could escape the positional arguments
14:41:27 stephenfin e.g. 'openstack server resize -- confirm'
14:41:34 stephenfin (not tested though)
14:41:47 stephenfin I'm sure someone will report the issue if it's really a big deal :-)
14:44:03 gibi stephenfin: $ openstack server resize --flavor d1 confirm
14:44:05 gibi seems to work
14:44:26 gibi where confirm is the name of the server
14:44:43 stephenfin that wouldn't work for server migrate though, I presume?
14:44:57 stephenfin Though i really should have called that 'server migration confirm'
14:44:57 gibi lets see
14:45:04 stephenfin In fact, I might yet do that
14:45:08 gibi $ openstack server resize confirm confirm
14:45:09 gibi works :D
14:45:51 dansmith please don't do that :)
14:45:58 gibi also you can do the trick
14:45:58 stephenfin openstack server create ... --wait confirm; openstack server resize confirm; # this won't though
14:45:59 gibi $ openstack server migrate --wait confirm
14:46:10 stephenfin ah, so you can
14:46:26 gibi you need a flag first then the server name :D
14:46:27 stephenfin Who's going to call their server 'confirm' anyway
14:46:31 gibi yeah
14:47:08 gibi famous last words :D
14:48:40 stephenfin while we're bikeshedding, 'server resize confirm' and 'server shelve offload' aren't really the same thing. We're confirming a "server resize" (or "server migration") which is a resource in its own right (you can list them). However there's no such thing as a "server shelve". It's a shelved server
14:49:04 stephenfin what about 'server shelve --offload', that will shelve and optionally offload?
14:49:12 gibi then you can add openstack server shelve-offload <server>
14:49:14 stephenfin we could check if the server was already shelved and only offload then
14:49:36 stephenfin I can't - hyphens aren't supported without special cliff config
14:49:49 stephenfin which is a couple of hundred lines of a patch /o\
14:50:29 gibi I'm fine with --offload
14:50:31 stephenfin (the config means use the entrypoint name as-is, meaning you need to remove all the underscores from the command entrypoints)
14:50:35 stephenfin sweet
14:50:55 gibi I think we are overcomplicating this
14:51:10 gibi but that is how we roll :)
14:51:49 stephenfin overengineering ftw
14:52:18 gibi we are paid to engineer so why not do it fully :D
14:53:07 gibi thinking more about poor VMs called 'confirm' or 'revert' I remembered https://xkcd.com/327/ so at least I'm happy now
14:53:34 stephenfin touché
15:02:01 sean-k-mooney stephenfin: shelve offload is done automatically
15:02:13 sean-k-mooney its not a api action
15:02:21 gibi it is
15:02:21 stephenfin it is
15:02:24 stephenfin jinx
15:02:28 sean-k-mooney to froce it
15:02:34 sean-k-mooney ?
15:02:36 stephenfin it's a host-level config
15:02:47 stephenfin shelved_offload_time
15:02:47 sean-k-mooney the offload time ya
15:02:55 sean-k-mooney it defautl to auto offloading
15:03:06 sean-k-mooney i guess we can set it to -1?
15:03:11 stephenfin you can, yes
15:03:15 sean-k-mooney or somethign to disable it
15:03:17 sean-k-mooney ok
15:03:24 stephenfin "Any value < 0: An instance will never offload."
15:03:25 sean-k-mooney that kind of feels like a bug
15:03:45 sean-k-mooney its not discoverable via the api
15:03:49 sean-k-mooney and it changes the workflow
15:03:59 sean-k-mooney normally peopel just shelve
15:04:09 sean-k-mooney and never have to assk for it to be offloaded
15:04:14 sean-k-mooney as that is the default behavior
15:04:31 sean-k-mooney so its chageign the meaning of shelve
15:05:19 stephenfin that's a fair point
15:05:26 stephenfin with that said, it's been this way since forever
15:06:24 sean-k-mooney would peopel be open to dissalowing values less then 0
15:07:11 sean-k-mooney shelve-offload is admin only https://github.com/openstack/nova/blob/master/nova/policies/shelve.py#L47-L58
15:07:32 sean-k-mooney shelve is allowed for tenants
15:07:40 stephenfin I have no thoughts either way on this
15:08:08 sean-k-mooney shelve unoffloaded is basicaly a more expensive power off and kind fo defets the reason for having shelve
15:08:25 sean-k-mooney which is to free the resouce on the host so other instance can use it
15:08:40 gibi there could be a long shelve_offload_time configure but the admin still want to get all the VMs that are shelve to be offloaded e.g. not migration shelve VMs due to host maintenance
15:09:01 sean-k-mooney gibi: a long time is fine
15:09:26 sean-k-mooney its the fact the workflow never actully gets to shelve offloaded if its -1 is the problem
15:09:39 sean-k-mooney you could not relay on that in heat for example currently
15:10:05 sean-k-mooney since heat wont be able to call shelve-offload by default and cant know what the config option is set too
15:10:07 gibi is there a different between an arbitrary big int and infinite?
15:10:37 sean-k-mooney practilly i guess not but making it admin only seams problematic
15:10:42 gibi or vice versa, do you have a meaningful upper limit for the timer
15:11:20 gibi yeah, I can be convinced that offload need to have the same policy default than shelve
15:11:24 sean-k-mooney honestly anthign over a hour or a day feels like its not working as intended
15:11:49 sean-k-mooney if they have the same policy default i dont really mind as much
15:12:12 sean-k-mooney espcially if we added "openstack server shelve --offload"

Earlier   Later