| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-11 | |||
| 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 | gibi | lets see | |
| 14:44:57 | stephenfin | Though i really should have called that 'server migration confirm' | |
| 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 | stephenfin | openstack server create ... --wait confirm; openstack server resize confirm; # this won't though | |
| 14:45:58 | gibi | also you can do the trick | |
| 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 | stephenfin | it is | |
| 15:02:21 | gibi | 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 | sean-k-mooney | the offload time ya | |
| 15:02:47 | stephenfin | shelved_offload_time | |
| 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" | |
| 15:12:53 | gibi | I thing stephenfin is working on this ^^ | |
| 15:13:04 | sean-k-mooney | so that it woudl do both if it was active or just offload if its shelved | |
| 15:13:06 | gibi | so at least half of it is in the works | |