Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-09-16
15:16:32 melwitt oh.. ok
15:16:37 melwitt thanks for explaining that bauzas
15:16:51 bauzas melwitt: sorry, my fault
15:16:56 bauzas I approved RC1 cut
15:17:04 bauzas but I should have thought about the reno patches
15:17:13 bauzas ideally the release team could make them dependent
15:17:22 bauzas between the release proposal and the reno update
15:17:42 gibi bauzas: this is not a fault. first we need to approve the release then the tooling proposes the stable branch creation and then the stable branch setup patches
15:18:03 bauzas that also explains why gibi was getting the notes
15:18:13 bauzas he didn't cut yet I guess :p
15:18:21 gibi I did not pull from remote
15:18:23 gibi so yes
15:18:34 bauzas et voila
15:18:40 bauzas even, et voilà
15:18:45 bauzas (with an accent)
15:18:54 melwitt fahncy
15:19:16 bauzas gibi: thanks for explaining
15:19:26 bauzas so the patches only appear once we branch ?
15:19:29 gibi I hope I'm correct :D
15:19:49 gibi bauzas: it cannot appeare before as there is no stable/xena to propose them against
15:20:04 bauzas that's an explanation :D
15:21:21 bauzas that now said, gibi, I didn't had time to work on sean-k-mooney's doc change
15:21:23 bauzas :/
15:21:34 bauzas I guess we should approve the prelude and cut RC1
15:21:39 gibi bauzas: then we go with the current reno
15:21:45 bauzas yeah
15:21:46 gibi then doc can be backported
15:21:53 bauzas we could update the prelude later
15:22:02 bauzas that works
15:22:03 gibi ok
15:22:19 bauzas it's just, we need a prelude section before RC1 in order to see it for 24.0.0
15:22:35 bauzas or the prelude would only appear in 24.0.1
15:22:44 gibi I see
15:22:45 gibi cool
15:22:59 bauzas but once we merge stuff for 24.0.0, touching the prelude would also update the 24.0.0 (if I'm not wrong)
15:23:21 bauzas that's one of the reno odds
15:24:11 bauzas dansmith has a point, revising the prelude
15:24:11 gibi ok, then merge the prelude
15:24:15 bauzas gibi: hold your approval
15:24:16 gibi ohh, sure
15:24:43 bauzas I mean, don't explicitely approve :p
15:25:51 opendevreview Sylvain Bauza proposed openstack/nova master: Add the Xena prelude section https://review.opendev.org/c/openstack/nova/+/807786
15:26:14 bauzas gibi: dansmith: melwitt: any other around ^
15:26:22 dansmith way ahead of you
15:26:50 gibi done
15:26:52 bauzas dansmith: man, you're way too much productive compared to me
15:27:08 dansmith I was just waiting for it after the mention above ;)
15:27:12 melwitt seeya soon, highlights o/
15:27:16 bauzas ++
15:27:33 dansmith oh man, an early morning melwitt spotting!
15:27:40 dansmith well, "early"
15:28:34 melwitt uh huh
15:29:01 dansmith :P
16:05:24 fungi elodilles: i noticed yesterday you were pushing forward on some nova stable branch changes (thanks!) and wanted to mention that the vmt is waiting for the rest of https://review.opendev.org/q/I95f68be76330ff09e5eabb5ef8dd9a18f5547866 to merge so we can publish errata for ossa-2021-002
16:06:19 fungi sean-k-mooney: on that note, the failures on 806629 imply that fix may not be backportable as-is to train?
16:07:03 fungi looks like it could be as simple as a couple of missing imports though
16:10:07 melwitt fungi: hm, looks like the original fix didn't merge yet on train as well
16:10:38 fungi melwitt: oh, interesting yeah
16:11:31 fungi that being 791807
16:11:40 melwitt fungi: I'll help review the ones that I didn't propose, I didn't realize we needed to wait for ussuri and train, I had thought the original fix notice went out after the victoria change merged
16:12:34 melwitt yeah
16:13:11 fungi melwitt: we need stable/ussuri merged first ideally in this case, since it's still in a maintained state (projected transition to extended maintenance is november)
16:13:37 melwitt fungi: ack, will prioritize
16:13:38 fungi i didn't realize the original train fix never got approved either
16:14:15 fungi but you're right that's less important, i can in theory link to the unmerged patch for train though i'm hesitant to do so unless it's actually passing ci jobs
16:15:18 fungi as i could be inadvertently encouraging someone to merge a change which just causes nova to start crashing
16:15:33 fungi er, to import a change into their deployment i mean
16:17:25 opendevreview Elod Illes proposed openstack/nova stable/ussuri: address open redirect with 3 forward slashes https://review.opendev.org/c/openstack/nova/+/806628
16:17:26 melwitt fungi: yeah makes sense. the train change (the original) is a combo of two patches squashed together bc a test change was needed in order for the test to run on python < 3.6. and the followup should be rebased over it
16:18:04 sean-k-mooney so presumable if we rebase the train one on top of the first patch that might fix it?
16:18:06 fungi aha, that 'splains the errors. i can push that
16:18:12 fungi unless someone else is already on it
16:19:21 fungi ahh, though there are merge conflicts between them as well, so i'll defer to someone familiar with doing nova backports
16:19:36 fungi i don't want to get the conflicts stuff in the commit message wrong
16:19:47 sean-k-mooney im on a call but if melwitt does not get to it i can try and stack them
16:19:54 fungi thanks!
16:20:37 elodilles fungi melwitt : I've updated the commit message of the ussuri patch ^^^
16:20:45 melwitt thanks elodilles
16:20:48 fungi thanks elodilles!!!
16:21:12 elodilles so that it's nice and clean (& ready to merge)
16:21:13 fungi trying to make sure this ossa update doesn't fall through the cracks
16:23:39 melwitt ++ thanks fungi
16:32:34 melwitt sean-k-mooney: I've got it
16:32:57 opendevreview Merged openstack/placement master: Update master for stable/xena https://review.opendev.org/c/openstack/placement/+/809365
16:34:40 opendevreview melanie witt proposed openstack/nova stable/train: address open redirect with 3 forward slashes https://review.opendev.org/c/openstack/nova/+/806629
16:34:46 clarkb Hello, I've got a cloud (the inmotion cloud you might see some of your CI jobs running on) that nodepool is failing to boot instances on.
16:35:11 clarkb the compute log says things like Instance f98ce366-90b1-43ba-8513-bf2ea559c931 has allocations against this compute host but is not found in the database.
16:35:27 clarkb and the conductor log says things like nova.exception_Remote.NoValidHost_Remote: No valid host was found.
16:35:48 clarkb `openstackclient limits show --absolute` shows that we aren't using any quota.
16:36:07 clarkb But it appears that nova is essentially saying the compute hosts are full up and it can't schedule more work?
16:36:37 melwitt clarkb: orphaned allocations in placement :( are making the hosts appear to be using resources when they shouldn't be
16:37:09 clarkb Is there a way to list those without digging into a database? osc server list is empty too
16:37:43 melwitt this is the doc for dealing with that https://docs.openstack.org/nova/latest/admin/troubleshooting/orphaned-allocations.html probably just need to run 'nova-manage placement heal_allocations' tool
16:37:49 clarkb thank you
16:39:44 fungi remember to lay your hands on the server when you chant "heal_allocations" too
16:40:22 fungi it doesn't really make the command work any better, but it looks cool if anyone happens to be walking by
16:40:37 melwitt 😂
16:42:56 melwitt this is just another reminder to prioritize the healing service (that would run heal_allocations periodically on its own, among other things) that's been in the backlog that I haven't had time to work on
16:58:26 opendevreview Merged openstack/nova master: Add the Xena prelude section https://review.opendev.org/c/openstack/nova/+/807786
17:40:34 melwitt elodilles: oh no, l-c job failure again https://review.opendev.org/c/openstack/nova/+/806628

Earlier   Later