Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-07-27
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
16:21:35 bauzas except maybe https://zuul.openstack.org/build/0e135bb912b240c8bc2aa96049727a1a
16:21:56 sean-k-mooney we know we have to do this every time we release it so we can prementivly submit the placment patch with a depens on the releases repo patch
16:21:56 bauzas oh nevermind, was fixed by the above
16:22:14 bauzas sean-k-mooney: you mean the placement release patch ?
16:22:19 sean-k-mooney yep
16:22:28 bauzas for m-3 ?
16:22:34 sean-k-mooney yes
16:22:40 sean-k-mooney well
16:22:48 sean-k-mooney when we go to release o-r-c again
16:23:00 sean-k-mooney we can prepare a patch to placment for it
16:23:23 sean-k-mooney to update the canary test and have it ready to go by depending on the pathch to the release repo
16:23:32 bauzas well, generally this is made by the release mgmt team but we can surely prepare it
16:23:36 sean-k-mooney im not sure if we will have anothger o-r-c release at m3
16:24:00 sean-k-mooney they will open the patch if we dont but they ask the ptl to approve
16:24:32 sean-k-mooney so at that point we can just do the house keeping patch for placnement and preappove ti so it will merge wehen the release patch does
16:24:45 bauzas they ask either the release folk or the PTL, yup :)
16:24:58 sean-k-mooney anyway we can move on just a tought
16:25:20 bauzas sean-k-mooney: keep your thought for next week when we get our ptl back
16:25:32 bauzas moving on
16:25:34 bauzas time is flying
16:25:49 bauzas Please look at the gate failures, file a bug, and add an elastic-recheck signature in the opendev/elastic-recheck repo (example: #link https://review.opendev.org/#/c/759967)
16:25:56 bauzas #topic Release Planning

Earlier   Later