| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-11 | |||
| 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 | stephenfin | I mostly know but can't come up with something succinct | |
| 15:17:50 | dansmith | stephenfin: snapshots the instance and re-schedule/deploys when you unshelve | |
| 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 | dansmith | not more expensive than a poweroff | |
| 15:20:38 | sean-k-mooney | but shelve-offloded is much cheaper | |
| 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 | |
| 15:23:13 | sean-k-mooney | i guess that makes some sense | |
| 15:23:56 | sean-k-mooney | it proably depend on the provider but i can see reducing at shelve too instead of shelve offloaded | |
| 15:24:22 | sean-k-mooney | anywya i think this is jsut an interop issue with the api | |
| 15:24:47 | sean-k-mooney | you cant really know what will happen when you call shelve i guess | |
| 15:25:06 | dansmith | that, and.. the only reason a user calls shelve is to save money | |
| 15:25:16 | dansmith | they have no idea when their resources will actually be freed, | |
| 15:25:40 | dansmith | they just know that they're saying "I'm telling you I won't need this for a while in exchange for some money back" | |
| 15:25:57 | dansmith | whether anything really happens immediately or later is not really their concern, | |
| 15:26:30 | dansmith | and they're not going to shelve it in order to pay more now, in hopes that they'll be charged less later when offload happens | |
| 15:26:31 | dansmith | it's not an investment :) | |
| 15:26:36 | sean-k-mooney | ya i guess when i use it locall its so i can back dev vms for feature x but i want to make capastiy for me to reuse | |
| 15:26:46 | dansmith | right, because you're on both sides of the curtain | |
| 15:27:01 | sean-k-mooney | ya | |
| 15:28:17 | sean-k-mooney | i guess its fine as it is | |
| 15:28:54 | sean-k-mooney | if i reset my expectation that the end state of shelve is one of (shelved, shelve_offloaded, error) | |
| 15:29:38 | sean-k-mooney | alot of our func test assume shleve_offloaded although that is fine since we can set teh config value if it matters in that test | |
| 15:30:10 | gibi | sean-k-mooney: a tangential question. Does nova support ports without IP allocation? I see https://review.opendev.org/#/c/669411 never merged, but I'm not sure we did other things to support it | |
| 15:30:32 | gibi | and I tried creating a neutron port with --no-fixed-ip | |
| 15:30:34 | sean-k-mooney | gibi: no | |
| 15:30:47 | sean-k-mooney | as far as i am aware we never enabled it | |
| 15:31:08 | gibi | yeah, I see Port 6370c969-73ca-41df-8c15-d91f10d44a59 requires a FixedIP in order to be used. (HTTP 400) with --no-fixed-ip ports | |
| 15:31:53 | sean-k-mooney | some of the concerns is that security groups and some qos policies may now work correctly | |