| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-11 | |||
| 17:12:07 | stephenfin | If someone reverts a resize, the expectation is that any data created on the instance between the resize and the revert will be lost, yeah? | |
| 17:12:32 | stephenfin | I mean, I know that will happen given how it's implemented, but I wonder if we ever documented that quirk anywhere? | |
| 17:12:55 | sean-k-mooney | if it not boot form volume yes | |
| 17:13:00 | sean-k-mooney | or rbd | |
| 17:13:13 | sean-k-mooney | if its using a qcow we wont copy it back | |
| 17:13:45 | sean-k-mooney | for rbd or bfv the data will be untoched and you wont lose anything | |
| 17:14:17 | stephenfin | Oh yeah. Boot from volume would be fine too | |
| 17:14:22 | openstack | Launchpad bug 1907179 in OpenStack Compute (nova) "resize revert will let new data lost!" [Undecided,Opinion] | |
| 17:15:24 | sean-k-mooney | one edgecase of note is what happens if we resize up then revert down for rbd? | |
| 17:15:34 | sean-k-mooney | e.g. if we go form 100G to 200G | |
| 17:15:41 | sean-k-mooney | will the rbd volume shrink? | |
| 17:16:10 | sean-k-mooney | for bfv you the root gb shoudl be ignored( well it shoudl be 0) but for RBD its used | |
| 17:16:36 | sean-k-mooney | if rbd grows the voluem which it should we cant safely shrink it on revert | |
| 17:16:44 | stephenfin | Hmm, that's a fair point. I haven't a clue tbh. Resize revert is a bit of an ugly duckling imo | |
| 17:16:48 | sean-k-mooney | unless we snapshot it | |
| 17:16:57 | sean-k-mooney | ya | |
| 17:16:59 | stephenfin | I suspect very few people, if any, use it regularly | |
| 17:17:49 | sean-k-mooney | ya, i have suggested removing it in the pastand the confrim step. for example in my recreate api propsosal | |
| 17:18:05 | sean-k-mooney | but not sure we can really do that | |
| 17:18:13 | sean-k-mooney | in the existing apis | |
| 17:18:38 | stephenfin | No really. The config option to auto-confirm after a set time is as close to that as we can get | |
| 17:18:51 | stephenfin | Implementation details leaking out of the API, ftw | |
| 17:18:52 | openstackgerrit | Merged openstack/nova-specs master: Re-propose "Secure Boot support for KVM & QEMU guests" for Wallaby https://review.opendev.org/c/openstack/nova-specs/+/759731 | |
| 17:19:59 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.resize_confirm_window | |
| 17:20:15 | sean-k-mooney | it would be nice if we could add a -1 to that | |
| 17:20:29 | sean-k-mooney | e.g. do it imedietly | |
| 17:20:37 | sean-k-mooney | normally i would call that 0 but that is taken | |
| 17:20:54 | sean-k-mooney | the best you can do now is set it to 1 second | |
| 17:20:56 | stephenfin | Good idea | |
| 17:21:30 | stephenfin | On another bug, you can't change the AZ of the host when there are instances on it, right? | |
| 17:21:40 | sean-k-mooney | correct | |
| 17:21:44 | stephenfin | We should probably have an API check to validate that | |
| 17:21:49 | sean-k-mooney | we do | |
| 17:22:00 | stephenfin | oh | |
| 17:22:05 | sean-k-mooney | its not backported to 13/train | |
| 17:22:05 | stephenfin | Is it recent? | |
| 17:22:12 | stephenfin | https://bugs.launchpad.net/nova/+bug/1907775 | |
| 17:22:12 | openstack | Launchpad bug 1907775 in OpenStack Compute (nova) "After change Host's Availability Zone, the deployed VMs Availability Zone data(in novaapi.request_specs table) can not be updated" [Undecided,New] | |
| 17:22:13 | sean-k-mooney | *queens | |
| 17:22:40 | sean-k-mooney | stephenfin: ill see if i can find it mriadem worte it i think | |
| 17:22:51 | stephenfin | no need, I'm looking | |
| 17:25:16 | sean-k-mooney | https://github.com/openstack/nova/blob/048250a4b76c0b6a85e459f92b436c448d592235/nova/compute/api.py#L6066 | |
| 17:25:32 | stephenfin | you're faster than me | |
| 17:25:51 | sean-k-mooney | i knew roughly where to look | |
| 17:26:19 | sean-k-mooney | https://github.com/openstack/nova/commit/0ad5a64dc9ac4b1cfb8038f9171b6385fdf07f28 | |
| 17:26:51 | stephenfin | hmm, I think that's different. That prevents us renaming an aggregates AZ | |
| 17:27:03 | sean-k-mooney | https://github.com/openstack/nova/commit/8e19ef4173906da0b7c761da4de0728a2fd71e24 | |
| 17:27:06 | sean-k-mooney | sorry ^ | |
| 17:27:10 | stephenfin | but it doesn't prevent us removing a host from an aggregate (and therefore the AZ) | |
| 17:29:09 | sean-k-mooney | we do it for add https://github.com/openstack/nova/blob/048250a4b76c0b6a85e459f92b436c448d592235/nova/compute/api.py#L6164 | |
| 17:29:31 | sean-k-mooney | stephenfin: we dont do it for remove | |
| 17:30:06 | sean-k-mooney | stephenfin: we should here ish https://github.com/openstack/nova/blob/048250a4b76c0b6a85e459f92b436c448d592235/nova/compute/api.py#L6211 | |
| 17:31:33 | sean-k-mooney | i guess line 6217 actully to be consitent | |
| 17:31:40 | sean-k-mooney | and do it after the notificaion | |
| 17:32:48 | sean-k-mooney | stephenfin: so that bug is half valid. what they are doing is not supported but we are not blocking the removal | |
| 17:32:56 | sean-k-mooney | it should be 1 line + tests however | |
| 17:32:59 | stephenfin | agreed | |
| 17:33:04 | stephenfin | I'm just creating a test now | |
| 17:33:06 | stephenfin | Easy win | |
| 17:33:27 | sean-k-mooney | i wonder why we did add but not remove in the first place | |
| 17:33:44 | stephenfin | not sure. It's very strange | |
| 17:33:56 | stephenfin | surprised no one has noticed before either | |
| 17:35:30 | sean-k-mooney | people dont do this often and we have a giant warning in the docs | |
| 17:36:54 | stephenfin | we do? | |
| 17:37:05 | stephenfin | about what? messing with AZs on hosts with instances? | |
| 17:37:49 | sean-k-mooney | ya i think spcificaly about moving host | |
| 17:39:55 | sean-k-mooney | https://docs.openstack.org/nova/latest/admin/availability-zones.html#implications-for-moving-servers | |
| 17:40:10 | sean-k-mooney | its got its own section | |
| 17:40:39 | sean-k-mooney | actully that not quite what i was thinking of | |
| 17:42:41 | sean-k-mooney | that partly covers it but i though we had addtion info specific to move compute nodes | |
| 17:43:35 | sean-k-mooney | hum i guess we dont | |
| 17:50:12 | stephenfin | sean-k-mooney: should you be allowed to add a host to an aggregate when it has instances on it? | |
| 17:50:58 | sean-k-mooney | no because if its not in an az it would be in an implcit nova az right | |
| 17:51:06 | stephenfin | good point | |
| 17:51:07 | sean-k-mooney | so that would result itn the instance moving az | |
| 17:51:27 | stephenfin | I was going to say it won't be in an AZ, but it will. The implicit one, as you note | |
| 17:51:31 | sean-k-mooney | it might be ok provide they dont have an explict nova request | |
| 17:51:46 | stephenfin | we tell people not to do that, iirc | |
| 17:52:16 | sean-k-mooney | yep here https://docs.openstack.org/nova/latest/admin/availability-zones.html | |
| 17:52:21 | sean-k-mooney | the warning at the top | |
| 17:52:39 | sean-k-mooney | but thats the edgecase you are hitting if you allow it | |
| 18:00:51 | JamesBenson | hey sean-k-mooney, one follow up question. Is there a setting (or benefit) to passing all of the CPU flags in the nova.conf in that mixed CPU environment we chatted about yesterday? | |
| 18:02:57 | sean-k-mooney | in your case i guess you could | |
| 18:03:24 | sean-k-mooney | since you are enableing flags not on the older host on your newer host you wont be able to migrate form westmer to nehelem anyway | |
| 18:03:37 | sean-k-mooney | you can move the other way | |
| 18:03:42 | sean-k-mooney | nehelem to westmer | |
| 18:03:58 | sean-k-mooney | so you could just use hostmodel or host passthough | |
| 18:04:10 | sean-k-mooney | normally you dont want ot do that if you have a mixed env | |
| 18:04:56 | openstackgerrit | Stephen Finucane proposed openstack/nova master: functional: Add reproducer for #1907775 https://review.opendev.org/c/openstack/nova/+/766771 | |
| 18:06:29 | stephenfin | sean-k-mooney: ^ | |
| 18:09:11 | sean-k-mooney | hehe you had to reformat things :P | |
| 18:09:56 | sean-k-mooney | so does that actuly work for both add and remove today | |
| 18:10:02 | sean-k-mooney | i was expect add to be blocked | |
| 18:12:27 | sean-k-mooney | stephenfin: hum they all pass so ya i guess its not blocked on add currently | |
| 20:02:20 | openstackgerrit | Lance Bragstad proposed openstack/placement master: Implement secure RBAC for resource providers https://review.opendev.org/c/openstack/placement/+/760240 | |
| 20:06:56 | openstackgerrit | Lance Bragstad proposed openstack/placement master: Implement secure RBAC for resource providers https://review.opendev.org/c/openstack/placement/+/760240 | |
| 20:06:57 | openstackgerrit | Lance Bragstad proposed openstack/placement master: Pass context objects to oslo.policy directly https://review.opendev.org/c/openstack/placement/+/766785 | |
| 20:44:40 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reproduce bug 1907522 in functional test https://review.opendev.org/c/openstack/nova/+/766791 | |
| 20:44:40 | openstack | bug 1907522 in OpenStack Compute (nova) "test_*_with_qos_min_bw_allocation fails in the nova-multi-cell job with: nova.exception.MigrationPreCheckError: Migration pre-check error: Failed to create port bindings for host |
|
| 21:38:22 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: WIP: Add 'socket' to NUMACell and PciDevice https://review.opendev.org/c/openstack/nova/+/766795 | |