| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-08-26 | |||
| 17:58:19 | dansmith | the attachment isn't deleted, so much later it complains that the instance is double-attached | |
| 17:58:46 | sean-k-mooney | well form the cinder side i guess it is | |
| 17:59:04 | sean-k-mooney | we could try and recover at that point and delete the old one again | |
| 17:59:16 | sean-k-mooney | which would possisble stop the leak | |
| 17:59:18 | dansmith | that's what I'm trying to avoid because it ends up a pretty nested mess | |
| 17:59:24 | sean-k-mooney | ah ok | |
| 17:59:38 | dansmith | and it's likely to fail in reality if we just failed to delete | |
| 18:00:27 | dansmith | I'm also not sure I know why we're detaching and re-attaching here, just to do the reimage | |
| 18:00:27 | sean-k-mooney | we are not doing the attchment delete before the save to prevent the other case right | |
| 18:00:38 | sean-k-mooney | where our db is now out of sync if we fail to save | |
| 18:00:41 | dansmith | must be some cinder reason why that happens, to reset the state while the instance is powered off or something | |
| 18:00:58 | dansmith | yeah I think we have to update our db before the delete for races | |
| 18:01:11 | sean-k-mooney | ya i think so too. | |
| 18:01:58 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (db) https://review.opendev.org/c/openstack/nova/+/831193 | |
| 18:01:59 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194 | |
| 18:01:59 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401 | |
| 18:02:00 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (api) https://review.opendev.org/c/openstack/nova/+/836830 | |
| 18:02:00 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (drivers and compute manager part) https://review.opendev.org/c/openstack/nova/+/833090 | |
| 18:02:01 | opendevreview | ribaudr proposed openstack/nova master: Bump compute version and check shares support https://review.opendev.org/c/openstack/nova/+/850499 | |
| 18:02:02 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach notification https://review.opendev.org/c/openstack/nova/+/850501 | |
| 18:02:02 | opendevreview | ribaudr proposed openstack/nova master: Add metadata for shares https://review.opendev.org/c/openstack/nova/+/850500 | |
| 18:02:03 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028 | |
| 18:02:04 | opendevreview | ribaudr proposed openstack/nova master: Add instance.power_on_error notification https://review.opendev.org/c/openstack/nova/+/852084 | |
| 18:02:04 | opendevreview | ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029 | |
| 18:02:06 | opendevreview | ribaudr proposed openstack/nova master: Add helper methods to attach/detach shares https://review.opendev.org/c/openstack/nova/+/852085 | |
| 18:02:06 | opendevreview | ribaudr proposed openstack/nova master: Add instance.power_off_error notification https://review.opendev.org/c/openstack/nova/+/852278 | |
| 18:02:08 | opendevreview | ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087 | |
| 18:02:08 | opendevreview | ribaudr proposed openstack/nova master: Add libvirt test to ensure metadata are working. https://review.opendev.org/c/openstack/nova/+/852086 | |
| 18:02:10 | opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to reboot method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/854823 | |
| 18:02:10 | opendevreview | ribaudr proposed openstack/nova master: Change microversion to 2.93 https://review.opendev.org/c/openstack/nova/+/852088 | |
| 18:02:12 | opendevreview | ribaudr proposed openstack/nova master: Support rebooting an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/854824 | |
| 18:02:19 | sean-k-mooney | i dont recall why but i rememebr lee disucsing this at some point | |
| 18:06:42 | sean-k-mooney | i dont see this dicussed in the ptg | |
| 18:07:14 | sean-k-mooney | ah | |
| 18:07:16 | sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/840155/5/specs/zed/approved/volume-backed-server-rebuild.rst#58 | |
| 18:07:31 | sean-k-mooney | #. Create an empty (no connector) volume attachment for the volume and | |
| 18:07:33 | sean-k-mooney | server. This ensures the volume remains ``reserved`` through the next | |
| 18:07:35 | sean-k-mooney | step. | |
| 18:07:37 | sean-k-mooney | #. Delete the existing volume attachment (the old one). | |
| 18:07:39 | sean-k-mooney | #. Save the new attachment UUID to the BDM. | |
| 18:07:41 | sean-k-mooney | #. The above two steps are needed to keep the volume in ``reserved`` state | |
| 18:07:43 | sean-k-mooney | as a management state which is required by cinder to perform re-image | |
| 18:07:45 | sean-k-mooney | operation on it. | |
| 18:07:47 | sean-k-mooney | #. Call the new ``os-reimage`` cinder API. | |
| 18:07:55 | dansmith | yeah, to reset the state basically I assume | |
| 18:08:24 | sean-k-mooney | we need to move it form in-use to reserved to reimage | |
| 18:11:20 | sean-k-mooney | honestly i feel like the way out of this if everything explodes is just call rebuild again | |
| 18:11:28 | sean-k-mooney | like wait for cinder to be back | |
| 18:11:43 | sean-k-mooney | and then the vm that is precumsble in error if we coudl not comptle the reimage later | |
| 18:11:52 | sean-k-mooney | could just be rebuilt again | |
| 18:12:18 | dansmith | yeah I assume that will work, as long as it's still in a reasonable state | |
| 18:12:19 | sean-k-mooney | kind of like what we do with a failed evacuate we just evacuate again | |
| 18:13:06 | dansmith | so I guess I'm just going to put it somewhat back the way it was, let it fail for all cases, but only call delete if we created the new attachment | |
| 18:13:14 | dansmith | right now it'll call delete(None) which I assume will fail | |
| 18:13:55 | sean-k-mooney | ya presumabley with a type/atibute error | |
| 18:14:14 | sean-k-mooney | None type has no attirbute uuid or something like that | |
| 18:15:00 | gibi | rebuild after a failed rebuild make sense to me too | |
| 18:16:01 | sean-k-mooney | i dont know if the precondtions on rebuild allow that | |
| 18:16:06 | dansmith | yeah, I'm not so concerned about that, I just want to make sure we haven't left things in too bad of a state where that's not possible | |
| 18:16:08 | sean-k-mooney | or if you would have to do reset state first | |
| 18:16:16 | dansmith | sounds to me like we're going to have leaked an attachment regardless | |
| 18:16:28 | dansmith | because we have nowhere to stash it and try to delete it later | |
| 18:16:28 | sean-k-mooney | yes | |
| 18:16:38 | sean-k-mooney | although the user can actully delete that if they wanted too | |
| 18:17:42 | sean-k-mooney | it would be a bit painful however | |
| 18:17:52 | sean-k-mooney | since they have no way to lsit teh bdms today | |
| 18:18:02 | sean-k-mooney | its not part of server detail show | |
| 18:18:34 | sean-k-mooney | i mena they coudl try deleteing all the attachments on a voluem but then nova and cinder are out of sync | |
| 18:19:01 | sean-k-mooney | so i think we woudl want to make sure they coudl juse rebuild again | |
| 18:19:09 | sean-k-mooney | rather then trying to repair it themselves | |
| 18:20:20 | dansmith | I think that will fail because of the double attachment | |
| 18:20:30 | dansmith | the same thing as when I failed the delete | |
| 18:20:38 | dansmith | but I dunno there's much we can do about that | |
| 18:56:56 | opendevreview | Rajat Dhasmana proposed openstack/nova master: add support for updating server's user_data https://review.opendev.org/c/openstack/nova/+/816157 | |
| 18:56:57 | opendevreview | Rajat Dhasmana proposed openstack/nova master: Add conductor RPC interface for rebuild https://review.opendev.org/c/openstack/nova/+/831219 | |
| 18:56:57 | opendevreview | Rajat Dhasmana proposed openstack/nova master: Add support for volume backed server rebuild https://review.opendev.org/c/openstack/nova/+/820368 | |
| 18:56:58 | opendevreview | Rajat Dhasmana proposed openstack/nova master: Add API support for rebuilding BFV instances https://review.opendev.org/c/openstack/nova/+/830883 | |
| 19:00:26 | ozzzo_work | We use the AggregateMultiTenancyIsolation filter for some aggregates, and for those aggregates we specify "filter_tenant_id = '(list of projects)' | |
| 19:00:57 | ozzzo_work | Today I'm hitting that filter for aggregates that do not have filter_tenant_id set | |
| 19:01:16 | ozzzo_work | This aggregate has no properties set at all | |
| 19:01:29 | ozzzo_work | 2022-08-26 17:48:49.879 33 INFO nova.filters [req-f57f505f-b3c8-42f5-acf7-5e5efe10ef83 a9219bb013c944edea6ba612b8fa704adc28d676f3ad1e326094350b8ff0c9c0 efc7139e50db483991df846c69b42477 - 8793b235debf49e6aba6bd1e2bf65360 8793b235debf49e6aba6bd1e2bf65360] Filtering removed all hosts for the request with instance ID 'e9f9292a-f1c0-409b-a47f-9fa596fd0965'. Filter results: ['ComputeFilter: (start: 50, end: 50)', 'RetryFilter: (start: 50, end | |
| 19:01:50 | ozzzo_work | looks like the line is too long | |
| 19:02:08 | ozzzo_work | https://paste.openstack.org/show/b5UFNxMB3oIlduDz1nat/ | |
| 19:02:12 | ozzzo_work | What could be causing that? | |
| 19:02:44 | dansmith | oye | |
| 19:02:50 | dansmith | whoami-rajat: did you make changes to that set or just rebase? | |
| 19:03:14 | whoami-rajat | dansmith, just rebased to resolve merge conflict, now working on changes | |
| 19:03:14 | dansmith | whoami-rajat: I should have made it more clear -- I was doing some work there, but was trying to avoid rebasing the other person's patch | |
| 19:03:22 | dansmith | figured I was safe since you said monday | |
| 19:03:30 | dansmith | whoami-rajat: hold on, I have a number of changes | |
| 19:03:37 | whoami-rajat | dansmith, oh sorry about that | |
| 19:03:39 | dansmith | I might as well push them up now that you rebased it | |
| 19:03:58 | whoami-rajat | ack, will wait then | |
| 19:04:18 | whoami-rajat | this microversion dependency doesn't seem good ... | |
| 19:08:47 | dansmith | ah, whoami-rajat I think you reverted the other person's latest rev with your push just now :( | |
| 19:09:04 | dansmith | yeah | |
| 19:09:09 | whoami-rajat | oh ... | |
| 19:09:43 | dansmith | okay so I'll just push up my stuff with a rebased version of their latest | |
| 19:10:26 | whoami-rajat | i think it's just better to break the dependency chain | |
| 19:10:45 | whoami-rajat | will need to do an extra rebase when their change is merged | |