| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-27 | |||
| 16:00:31 | stephenfin | o/ | |
| 16:00:39 | bauzas | howdy folks I'll be your chair for this meeting given our Supreme Leader is on vacations | |
| 16:00:50 | bauzas | \o | |
| 16:00:53 | sean-k-mooney | o/ | |
| 16:01:21 | bauzas | awesome, one more people from the last meeting I chaired \o/ | |
| 16:01:46 | bauzas | agenda is up at https://wiki.openstack.org/wiki/Meetings/Nova | |
| 16:01:58 | elodilles | o/ | |
| 16:02:27 | bauzas | feel free to add items you wanna discuss in the last section above ^ | |
| 16:02:31 | bauzas | moving on now | |
| 16:02:33 | bauzas | #topic Bugs (stuck/critical) | |
| 16:02:41 | bauzas | No Critical bugs | |
| 16:02:48 | bauzas | #link 11 new untriaged bugs (+1 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New | |
| 16:02:58 | bauzas | I'll try to look at some of them tomorrow | |
| 16:03:14 | bauzas | any other bugs people wanna raise ? | |
| 16:03:46 | stephenfin | nope, we had a gate issue due to Sphinx 4.x but sean-k-mooney fixed that for us | |
| 16:04:11 | bauzas | we could have had a cinderclient bug, but the v3 change is now merged, right? | |
| 16:04:22 | bauzas | stephenfin: excellent, thanks sean-k-mooney | |
| 16:04:22 | sean-k-mooney | ya i think that is merged now | |
| 16:04:28 | stephenfin | Yes, the nova one landed last week and the novaclient one went in earlier today | |
| 16:04:41 | bauzas | oki doki | |
| 16:04:58 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/802334 | |
| 16:04:59 | bauzas | were we limiting the cinderclient version ? | |
| 16:05:02 | sean-k-mooney | that was the nova one | |
| 16:05:15 | sean-k-mooney | bauzas: no we jsut had a refernce to v2 | |
| 16:05:22 | bauzas | ok | |
| 16:05:28 | sean-k-mooney | replced it with v3 | |
| 16:05:28 | bauzas | anyway, moving | |
| 16:05:40 | bauzas | #topic Gate status | |
| 16:05:46 | bauzas | Nova gate bugs #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure | |
| 16:06:33 | bauzas | #topic Gate status | |
| 16:07:02 | bauzas | meh, maybe the meetbot works with the #topic section | |
| 16:07:03 | bauzas | anyway | |
| 16:07:14 | bauzas | nothing to say about any gate issue ? | |
| 16:07:40 | stephenfin | nope, not beyond the above | |
| 16:07:42 | bauzas | I can see a new one from lyarwood https://bugs.launchpad.net/nova/+bug/1938021 | |
| 16:08:13 | sean-k-mooney | we are still using the tempoary workaround for the ovsdb issue. ill try and find out how the ovs change is comming before m3 but no other update on that | |
| 16:08:45 | sean-k-mooney | hum interesting | |
| 16:08:52 | melwitt | I have noticed while working on placement consumer types that a generation conflict gets hit on my patches, let me find the (old) gate bug | |
| 16:08:53 | sean-k-mooney | was tehre a new olo release | |
| 16:09:24 | bauzas | sean-k-mooney: good question | |
| 16:09:37 | melwitt | this one http://bugs.launchpad.net/bugs/1836754 | |
| 16:10:20 | sean-k-mooney | bauzas: the messging issue might be related to something moving and we are nolonger mocking properly in the func tests | |
| 16:10:43 | bauzas | melwitt: heh, who is working on this one ? | |
| 16:10:46 | melwitt | it occurs in general too but while working on placement to do more during a PUT it makes it happen a lot more. so a heads up that I think we'll need to address that before placement consumer types will be usable | |
| 16:10:48 | sean-k-mooney | although perhaps not it is corectly using the fake implementation. | |
| 16:11:09 | bauzas | melwitt: oh it's you | |
| 16:11:21 | sean-k-mooney | huh i could see that conflict happening alright | |
| 16:11:39 | melwitt | bauzas: I have restored mriedem's old patch about the bug and will add tests to it for review | |
| 16:11:47 | bauzas | do we have race conditions for this a lot ? (the conflict) | |
| 16:11:55 | melwitt | yeah, it was originallly from tssurya and cdent but both moved off of openstack before it was finished so I've been working on finishing it | |
| 16:12:06 | bauzas | or is it just for a few job runs ? | |
| 16:12:37 | melwitt | bauzas: I have seen it on other patches yes, but not nearly as often as I do on the placement patches. on the placement patches it looks pretty much guaranteed | |
| 16:12:46 | sean-k-mooney | well im not sure the frequency matteers with the scale we run at its goign to block patches at least temporaly and require a recheck | |
| 16:13:22 | sean-k-mooney | so i think we should try an fix it sooner rather then later | |
| 16:13:32 | bauzas | melwitt: so we get a conflict when deleting the allocation but why are we getting an exception ? | |
| 16:13:50 | bauzas | the allocation should just be orphaned, that's it | |
| 16:13:53 | melwitt | just wanted to give everyone a heads up about it because back when the fix was proposed, it there was a lot of discussion on the review. so if anyone has concerns about DELETE for most allocations cases rather than PUT, comment on the review | |
| 16:14:10 | bauzas | melwitt: sure, will review your change if you want | |
| 16:14:14 | melwitt | because it was changed to a PUT instead of a DELETE when consumer generations were added | |
| 16:14:21 | bauzas | ah shit, I see | |
| 16:14:34 | melwitt | it's mriedem's change that I'm going to complete | |
| 16:14:37 | bauzas | melwitt: thanks for working on it either way | |
| 16:14:57 | sean-k-mooney | melwitt: wait deleting an allocation was chgange to a put? | |
| 16:15:35 | sean-k-mooney | because what delete dont have a body and we did not want to include the consomer generation in the query arg? | |
| 16:15:38 | bauzas | sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/688802/2/nova/scheduler/client/report.py#b2107 | |
| 16:15:38 | melwitt | here's the review https://review.opendev.org/c/openstack/nova/+/688802 | |
| 16:15:40 | melwitt | sean-k-mooney: yes, https://review.opendev.org/c/openstack/nova/+/591597 | |
| 16:15:47 | melwitt | sean-k-mooney: I don't know, tbh | |
| 16:15:51 | bauzas | sean-k-mooney: we now call put() | |
| 16:16:02 | sean-k-mooney | well that by itself is a bug | |
| 16:16:13 | melwitt | I tend to agree | |
| 16:16:21 | sean-k-mooney | we should not use put for delete and im not convince we need to even include the generation version | |
| 16:16:44 | bauzas | let's discuss this after the meeting, if people want | |
| 16:16:53 | sean-k-mooney | sure | |
| 16:16:56 | bauzas | but I tend to agree too | |
| 16:17:08 | bauzas | I need to understand the *why* for put | |
| 16:17:18 | bauzas | so looking at the original change | |
| 16:17:23 | bauzas | anyway | |
| 16:17:24 | bauzas | moving on | |
| 16:17:36 | bauzas | Placement periodic job status #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly | |
| 16:17:40 | melwitt | the only thing you get with PUT is if you issue a delete of your instance, if someone else updates it while it's deleting, you have a chance to reconsider your decision to delete it. afaik that might be the reasoning | |
| 16:18:06 | bauzas | melwitt: yeah, that's what I think too | |
| 16:18:12 | bauzas | for a race | |
| 16:18:16 | bauzas | anyway | |
| 16:18:26 | melwitt | yeah sorry, can move on | |
| 16:18:28 | bauzas | about the placement periodic job, well, we merged stuff | |
| 16:18:31 | sean-k-mooney | ya that is what i assuem too but i dont think that is the right design choice if we delete it we shoudl just delete it | |
| 16:18:31 | bauzas | last week | |
| 16:18:40 | bauzas | now the job looks to work | |
| 16:18:51 | bauzas | (we merged a now o-r-c) | |
| 16:18:59 | bauzas | *version | |
| 16:19:02 | sean-k-mooney | o-r-c | |
| 16:19:06 | sean-k-mooney | ?? | |
| 16:19:20 | sean-k-mooney | oh os-resouce-classes | |
| 16:19:26 | sean-k-mooney | yes | |
| 16:20:14 | sean-k-mooney | placment was updated to account for the new os-resource-class release | |
| 16:20:26 | bauzas | yeah, sorry was triying to find the patch | |
| 16:20:37 | bauzas | https://review.opendev.org/c/openstack/placement/+/796595 | |
| 16:20:52 | bauzas | anyway, nothing to tell more | |
| 16:21:13 | sean-k-mooney | one thing we might want to consider it preparing the patch when we are preparing the release | |