| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-11 | |||
| 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" | |
| 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 | |
| 15:13:13 | stephenfin | sean-k-mooney: yes, exactly | |
| 15:13:19 | sean-k-mooney | well i dont think you shoudl have to do two actions | |
| 15:13:32 | sean-k-mooney | when you do shelve the expectation is it evenutally end up in offloaded | |
| 15:13:49 | stephenfin | I'll admit, that confused me. I thought the shelveOffload action would both shelve and offload, but it only does the latter | |
| 15:14:04 | stephenfin | I can mask that in the CLI | |
| 15:14:06 | stephenfin | though | |
| 15:14:13 | sean-k-mooney | ya you would have to do it in the cli | |
| 15:14:39 | sean-k-mooney | but i think tis come down to the default behavior of shleve which is to offload imedietly | |
| 15:15:19 | dansmith | the default is not to offload immediately, | |
| 15:15:23 | dansmith | unless the timer is zero right/ | |
| 15:15:32 | sean-k-mooney | yes we default to 0 i think | |
| 15:15:45 | dansmith | oh, really? I surely didn't think so | |
| 15:16:11 | dansmith | yep, you're right | |
| 15:16:14 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/conf/compute.py#L1134-L1155 | |
| 15:16:53 | sean-k-mooney | ya so i have never done shelve-offload before but i use shelve semi frequently | |
| 15:17:19 | sean-k-mooney | and i have always expected it to go to shelve offloaded | |
| 15:17:29 | dansmith | offload timer of zero makes it behave more like aws' stop I think | |
| 15:17:34 | stephenfin | can anyone give me a one line summary of what shelve does vs. shutdown? | |
| 15:17:39 | dansmith | which maybe is why the default is there | |
| 15:17:46 | sean-k-mooney | dansmith: yep | |
| 15:17:50 | dansmith | stephenfin: snapshots the instance and re-schedule/deploys when you unshelve | |
| 15:17:50 | stephenfin | I mostly know but can't come up with something succinct | |
| 15:17:58 | stephenfin | dansmith++ ta | |
| 15:18:29 | dansmith | stephenfin: but only if it was offloaded, so you can't say it always does that | |
| 15:18:31 | sean-k-mooney | stephenfin: then shelve offload deletes it form the host and frees the calimed resources after shelve | |
| 15:18:32 | dansmith | although the client shouldn't really care whether it does or not | |
| 15:18:54 | sean-k-mooney | dansmith: do we defer the snapshot to offload | |
| 15:18:59 | dansmith | stephenfin: it was added as a way to keep your uuid and ip, but charge you less while the instance was "off" since it wasn't using memory and disk on the compute | |
| 15:19:08 | sean-k-mooney | i guess that makes sesne i though it was in the shelve step though | |
| 15:19:10 | sean-k-mooney | its been a while | |
| 15:19:28 | dansmith | sean-k-mooney: pretty sure we snap immediately, so that the offload can be independent and fast when it happens | |
| 15:20:02 | sean-k-mooney | ya so basically form a resouce point of view shelved is like powered off + a snapshot | |
| 15:20:24 | sean-k-mooney | so its more expensive since you are also being changed for the snapshot vs poweroff | |
| 15:20:31 | dansmith | no, | |
| 15:20:35 | dansmith | it's more expensive than a snapshot, | |
| 15:20:38 | sean-k-mooney | but shelve-offloded is much cheaper | |
| 15:20:38 | dansmith | not more expensive than a poweroff | |
| 15:20:47 | dansmith | well, depends I think | |
| 15:20:59 | dansmith | I think RAX would charge you less once you're in the shelved state, | |
| 15:21:09 | dansmith | because they could reclaim your resources at any point, so it didn't really matter and thus wasn't costing you more | |
| 15:21:27 | dansmith | if anything, the not-yet-offloaded state saved *them* resources having to redeploy your snapshot if you unshelved quickly | |
| 15:21:36 | sean-k-mooney | well tehy are only allowed to reclaim the resouce once it hits offloaded right | |
| 15:21:47 | sean-k-mooney | ya | |
| 15:21:51 | sean-k-mooney | that is why its there | |
| 15:21:55 | sean-k-mooney | the quick resume | |
| 15:22:03 | dansmith | the compute only gets the resources back on offload, but once you're shelved they could do that whenever they want, | |
| 15:22:15 | dansmith | so it's basically cache at that point | |
| 15:22:43 | dansmith | the client doesn't know when (or if ever) the offload will happen, so charging them more for some indeterminite period of time, and then cutting them down to cheaper on offload doesn't make any sense | |