| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-08-26 | |||
| 18:02:04 | opendevreview | ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029 | |
| 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:06 | opendevreview | ribaudr proposed openstack/nova master: Add instance.power_off_error notification https://review.opendev.org/c/openstack/nova/+/852278 | |
| 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: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:08 | opendevreview | ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087 | |
| 18:02:10 | opendevreview | ribaudr proposed openstack/nova master: Change microversion to 2.93 https://review.opendev.org/c/openstack/nova/+/852088 | |
| 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: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 | sean-k-mooney | yes | |
| 18:16:28 | dansmith | because we have nowhere to stash it and try to delete it later | |
| 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 support for volume backed server rebuild https://review.opendev.org/c/openstack/nova/+/820368 | |
| 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: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 | 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:14 | whoami-rajat | dansmith, just rebased to resolve merge conflict, now working on changes | |
| 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 | |
| 19:11:42 | whoami-rajat | i can see how it happened, their change was not latest and my patches were not rebased on their latest | |
| 19:11:47 | whoami-rajat | should've been more careful there :/ | |
| 19:11:55 | dansmith | whoami-rajat: right, I had it all set locally, | |
| 19:12:08 | dansmith | and breaking the chain just means we'll have to do more version switching if we do that | |
| 19:12:10 | dansmith | just a sec | |
| 19:12:19 | opendevreview | Dan Smith proposed openstack/nova master: add support for updating server's user_data https://review.opendev.org/c/openstack/nova/+/816157 | |
| 19:12:20 | opendevreview | Dan Smith proposed openstack/nova master: Add support for volume backed server rebuild https://review.opendev.org/c/openstack/nova/+/820368 | |
| 19:12:20 | opendevreview | Dan Smith proposed openstack/nova master: Add conductor RPC interface for rebuild https://review.opendev.org/c/openstack/nova/+/831219 | |
| 19:12:21 | opendevreview | Dan Smith proposed openstack/nova master: Add API support for rebuilding BFV instances https://review.opendev.org/c/openstack/nova/+/830883 | |
| 19:12:35 | whoami-rajat | yeah 2.94 after 2.92 will break something surely | |
| 19:12:43 | ozzzo_work | Is this the right channel to ask about nova filters? | |
| 19:13:01 | dansmith | ozzzo_work: this is really for nova development not help, and it's friday afternoon | |
| 19:13:15 | dansmith | whoami-rajat: so in the main patch I broke apart that error handler for the issue we noted there, | |
| 19:13:30 | ozzzo_work | ok I'll try emailing the list | |
| 19:13:31 | dansmith | whoami-rajat: and in the last one I made the test less mock-heavy and added some negative cases | |
| 19:13:37 | dansmith | ozzzo_work: that'd be better | |
| 19:15:10 | whoami-rajat | dansmith, great, i was just thinking about how to break those exception blocks, thanks | |
| 19:16:33 | dansmith | whoami-rajat: I don't think we need to be fully covered in the functional tests, but I included several error paths, so I hope that's good enough, assuming I didn't break any unit tests.. more unit tests for covering all the potential exit paths is still good of course | |
| 19:17:40 | whoami-rajat | ack, will take a look | |
| 19:18:58 | dansmith | all the brought-forward comments are referring to the wrong lines in the latest PS instead of being collected up at the top, that's very weird | |
| 19:19:16 | dansmith | IMHO you can resolve those and let people re-comment if they want | |
| 19:19:53 | whoami-rajat | yeah that happens, I'm on the same patchset when the comments were left and it looks fine like that | |