| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-11 | |||
| 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 | |
| 15:32:07 | sean-k-mooney | also the metadata api woudl not work | |
| 15:33:11 | sean-k-mooney | for l3 only backend like callico you also would have no network connectivty as you cant fall back to l2 in that case | |
| 15:33:40 | gibi | so I guess this cannot be added to nova generally, we have to somehow special case it if we need it | |
| 15:34:00 | sean-k-mooney | we now have the connectivity in the port | |
| 15:34:12 | sean-k-mooney | it will be either legacy l2 or l3 i belive | |
| 15:34:24 | sean-k-mooney | so we could allow it for l2 ports and maybe legacy | |
| 15:34:32 | sean-k-mooney | legacy was for backend that did not say | |
| 15:34:39 | sean-k-mooney | but your milage would vary | |
| 15:34:52 | gibi | thanks | |
| 15:35:18 | sean-k-mooney | actully rodolfos patch already has that https://review.opendev.org/#/c/669411/1/nova/network/neutronv2/api.py | |
| 15:36:33 | gibi | so that handles the l3 only backend case, what can we do with secgroups? | |
| 15:37:04 | sean-k-mooney | am well secgroups almost always deals with l3+ | |
| 15:37:20 | sean-k-mooney | so if you have no ip then you can only use the ethertype rule | |
| 15:37:32 | sean-k-mooney | neutron will still do mac spoofing protection | |
| 15:37:41 | sean-k-mooney | i dont think we need to care about that | |
| 15:37:56 | sean-k-mooney | well we can care we just dont need to do anything | |
| 15:38:16 | gibi | OK, so we could repropos rodolfo's patch if we want | |
| 15:38:27 | sean-k-mooney | yep i have no issue with doing that | |
| 15:38:35 | sean-k-mooney | ie proceedign with it | |
| 15:38:46 | sean-k-mooney | he already did the neutron feature | |
| 15:38:53 | sean-k-mooney | which is what it was waiting on really | |
| 15:39:02 | sean-k-mooney | https://review.opendev.org/#/c/645645/ | |
| 15:39:52 | sean-k-mooney | now that ovn is in tree we might want to make sure that reporst the attibute as l2 but other then that i dont see a blocker here | |
| 15:41:09 | sean-k-mooney | i think its kind of expected that if you have an adressless port that you cant use things like floating ips which neutron should block for us | |
| 15:41:11 | gibi | sean-k-mooney: thanks. I might repropose that at some point as it seem there is downstream need for it | |
| 15:41:48 | sean-k-mooney | we had a downstream request too at one point but it was obviously not a high priorit since its still pending | |
| 15:42:46 | sean-k-mooney | ovn is also updated fyi https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py#L171 | |
| 15:43:02 | sean-k-mooney | so it looks like everything is in place on the neutron side | |
| 15:43:28 | gibi | coolio | |
| 15:43:43 | gibi | I still not get the priority info hence the conditional from my side too | |
| 15:43:49 | gibi | let see | |
| 15:44:14 | zigo | sean-k-mooney: It IS included, it's just done in openstack-pkg-tools automatically. | |
| 15:45:08 | zigo | Also, nova-compute.conf only contains a few hypervisor specifics for switching virtualization depending on which nova-compute-FOO you install. | |
| 15:45:33 | zigo | ie: nova-compute-qemu will install qemu as virt driver, nova-compute-kvm will do kvm, etc. | |
| 15:45:40 | zigo | But everything else is in nova.conf ... | |
| 15:52:31 | sean-k-mooney | zigo: ya i saw they were minimal | |
| 15:52:51 | sean-k-mooney | so ideally you would do one of two things move the db and api db config into there own files | |