Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-07-27
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 melwitt here's the review https://review.opendev.org/c/openstack/nova/+/688802
16:15:38 bauzas sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/688802/2/nova/scheduler/client/report.py#b2107
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 bauzas last week
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: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 bauzas oh nevermind, was fixed by the above
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: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
16:26:02 bauzas We past M2 and spec freeze. M3 is in 5 weeks.
16:26:10 bauzas We have 21 approved an open blueprints and we have 5 weeks to finish them. Please focus review effort on bps in Needs Code Review state.
16:26:29 bauzas that reminds me, people have to make sure their blueprint is on Needs Code Review
16:26:51 bauzas #link https://launchpad.net/nova/+milestone/xena-3
16:27:35 bauzas the delivery status doesn't really mean anything but that can help reviewers to know which series to look at
16:27:49 bauzas so, if you love reviews, you know what to do
16:28:19 bauzas Next deadline is non-client library freeze at 16th of August
16:28:43 bauzas think about it for os-resource-class ;)
16:28:58 bauzas moving on
16:29:06 bauzas #topic PTG Planning
16:29:14 bauzas PTG timeslots booked by gibi, see #link http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023787.html
16:29:24 bauzas The PTG etherpad is ready to be filled with topics: #link https://etherpad.opendev.org/p/nova-yoga-ptg
16:29:37 bauzas If you see a need for a specific cross project section then please let gibi know
16:30:22 bauzas I'm pretty sure this etherpad will be filled before we have the PTG :)

Earlier   Later