| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-08-26 | |||
| 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 | |
| 19:20:13 | whoami-rajat | left view: old PS with comments, right view: new PS | |
| 19:22:19 | dansmith | right, but if you have base on the left and current on the right, it is supposed to show the comments on unchanged lines, or at the top if they've been changed | |
| 19:22:22 | dansmith | and this is showing them on the wrong lines | |
| 19:23:16 | dansmith | actually hard refresh seems to have fixed it, | |
| 19:23:27 | dansmith | so maybe just a caching bug or something | |
| 19:23:31 | whoami-rajat | yep, I've also been struggling with that recently | |
| 19:23:35 | whoami-rajat | ah really? | |
| 19:24:21 | whoami-rajat | yep that fixed it, nice | |
| 19:24:29 | dansmith | haven't seen that before | |
| 19:27:28 | sean-k-mooney | ozzzo_work: quick glance not sure | |
| 19:29:36 | sean-k-mooney | dansmith: ya i often have to go to the patset the comment was left on to make any use out of that feature | |
| 19:30:51 | sean-k-mooney | ok im starting to get hungery so im going to finish there for today. | |
| 19:31:04 | sean-k-mooney | i will keep an eye on those patches | |
| 19:31:33 | sean-k-mooney | i assume at this point however that it will be monday for the base patch to be ready | |
| 19:54:14 | whoami-rajat | sean-k-mooney, if you're still around, I've a question | |
| 19:54:38 | whoami-rajat | sean-k-mooney, regarding your comment here https://review.opendev.org/c/openstack/nova/+/820368/comments/711f86cd_9c3731a4 | |
| 19:55:05 | whoami-rajat | sean-k-mooney, if we want to support it for the ironic use case, we would have to provide a generic driver implementation and also implemented it for the libvirt driver right? | |
| 19:55:22 | dansmith | whoami-rajat: ironic is the only one that provides its own rebuild implementation, AFAIK | |
| 19:55:39 | whoami-rajat | looking | |
| 19:55:43 | dansmith | whoami-rajat: I think what you need to do is modify ironic's rebuild to check for the flag and fail if it's requested (for now) | |
| 19:55:55 | dansmith | and obviously pass the flag to it as sean mentions | |
| 19:56:09 | dansmith | whoami-rajat: getting it to work with ironic will require work on the ironic side, which obviously isn't going to happen | |