Earlier  
Posted Nick Remark
#openstack-nova - 2024-03-14
15:11:05 sean-k-mooney this is entirly approate to disucss here
15:11:17 bauzas sean-k-mooney: gibi: dansmith: https://review.opendev.org/c/openstack/nova/+/912973 prelude is open for reviews
15:11:18 sean-k-mooney artom was askign if we shoudl consider backportign to unmaintend branhces
15:11:28 sean-k-mooney and i say we can do that if we want to for other reasons
15:11:41 sean-k-mooney but form a core or stable core perspective we do not maintian those
15:11:48 sean-k-mooney and are not expected to do backport to them
15:11:57 artom I don't think it's a surprise that Red Hat has a downstream product, and that we do cherry-picks :)
15:12:07 artom It's not like we're discussing downstream-only code changes here
15:12:32 sean-k-mooney right so i was just trying to provide guidence that we shoudl default to backporting to stable/*
15:12:39 artom Oh, totally
15:13:00 sean-k-mooney and unmaintained/* is optional but not expected
15:13:04 artom As far back as is reasonably possible.
15:13:05 artom Yep.
15:13:36 sean-k-mooney if we are backporting downstream past stable/* it does not hurt to provide the patches publicly but if peopel choose not to it that ok too
15:14:06 sean-k-mooney i prefer when our backprots upstream or downstream are made avaiabel to as wide an audinace as possibel so i prefer upstrema first to be our default
15:19:24 bauzas for sure
15:19:48 bauzas I was just saying to make sure we don't need to discuss about our downstreack backports here
15:20:28 sean-k-mooney yep i just wanted artom to start on the upstream one and we can figure out downsteam when wever that becomes relevent
15:20:28 bauzas not because of security, but rather Red Hat is not the only company working upstream :)
15:21:02 bauzas (and it was just a reminder that we log everything here : https://meetings.opendev.org/irclogs/%23openstack-nova/ )
15:21:23 artom sean-k-mooney, they're all posted anyways, even the downstream ones :)
15:22:24 artom bauzas, I know this is a public channel - again, I don't think it's a surprise to anyone, or is secret information, that Red Hat has a downstream product with cherry-picks :) And that's there the mention of it ends, nothing further will be discussed
15:23:03 bauzas no worries, but maybe not all of us know about the logs :) )
15:24:07 sean-k-mooney i do and im sure artom does so is it new info to you?
15:25:11 artom I was totally about to post by credit card PIN
15:25:55 sean-k-mooney password:
15:25:58 sean-k-mooney :)
15:26:45 sean-k-mooney anyway i got distracted by thing ill go back and review Uggla patch now
15:32:59 artom See, then you typed your password, I saw *****, but you saw hunter2, because IRC is smart like that
15:59:57 opendevreview Sylvain Bauza proposed openstack/nova master: Update compute rpc alias for caracal https://review.opendev.org/c/openstack/nova/+/912617
16:00:21 bauzas dansmith: gibi: sean-k-mooney: yet another paperwork change for RC1 ^
16:00:36 bauzas (just updated it b/c of the new RPC version we just added)
16:03:56 sean-k-mooney ack im +2 on https://review.opendev.org/c/openstack/nova/+/877773 by the way
16:20:13 gibi I'm +2 the RPC alias
17:04:09 bauzas elodilles: sean-k-mooney: I just figured out (my bad) that we still have a few open patches in placement that could be merged before RC1 https://review.opendev.org/q/project:openstack/placement+is:open
17:04:22 bauzas https://review.opendev.org/c/openstack/placement/+/907742 seems at least nice to have
17:23:30 sean-k-mooney the slurp job can merge at any point
17:23:40 sean-k-mooney we can trivially just backport that to the stable branch
17:23:49 sean-k-mooney but i agree it woudl be nice to have
17:49:09 elodilles bauzas: ACK, thanks for signaling it on the release patch!
17:49:25 elodilles (though you linked a nova patch there o:))
18:37:27 melwitt sean-k-mooney: speaking of persistent mdevs, I think it's ready for review if you were wondering https://review.opendev.org/c/openstack/nova/+/910041
18:38:38 sean-k-mooney how did testing host reboot go. were you able to do it with the sytemd service file?
18:40:01 sean-k-mooney melwitt: this is for dalmation ya so i can try and review it but we need to wait for RC1 to ship before merging i guess
18:41:09 sean-k-mooney this is pretty localised within the libvirt code so im not really concerned with this havign issues with other RCs so i would be ok ewith merging this once we reapprove the blueprint from a paperwork perpwective
18:41:14 melwitt sean-k-mooney: yeah, no rush obvs. I've been intentionally not bringing it up but just so you're aware. I don't expect review until later on
18:41:28 sean-k-mooney cool
18:42:11 melwitt sean-k-mooney: I didn't think to try the systemd way for some reason. I only did it manually. I'll try systemd next
18:42:43 melwitt I did remember to put the systemd mention into docs/ in that patch 😛
18:42:53 sean-k-mooney ack if your including the doc update with the systemd script then ya it would be good to test that locally
18:43:20 sean-k-mooney yep its teh second ting i read after the commit message
18:43:31 melwitt yeah. agree
18:45:34 sean-k-mooney oh i see your supproting eithe rway based on the libvirt version
18:46:14 melwitt yeah.. initially I didn't do that but realized it later. we would need a min version bump to not have to do it I think
18:46:28 sean-k-mooney am that will not strictly be required as we can move to libvirt 8.0.0 next cycle
18:46:38 sean-k-mooney but since you have it working we can keep it
18:46:45 melwitt which we might be doing for dalamation, so I can take that out if so
18:47:31 melwitt it would make the change much prettier if we bumped to 8.0.0 heh
18:47:55 sean-k-mooney ya although its not terrible as is
18:47:56 melwitt persistent mdevs in 7.3.0 and autostart in 7.8.0
18:48:46 sean-k-mooney autostart in this context being create them automatically on host start right
18:48:51 sean-k-mooney rather then domain start
18:49:30 sean-k-mooney may be worth adding follow up patches that do the min bump
18:49:55 sean-k-mooney and we can then defer that choice until we decied if we bump to 8.0.0
18:50:54 sean-k-mooney it looks like there would not actully be much clean up to do fo 8.0.0
18:51:57 sean-k-mooney i mean for other feature
18:52:11 sean-k-mooney all the feature gates seam to be 8.y.z
18:52:29 sean-k-mooney so i dont think you will need to do much cleanup if you decied to creat that patch
18:55:28 melwitt sean-k-mooney: yes autostart is the virNodeDeviceCreate happening automatically at host start
18:55:32 melwitt I also added a thing to do it during init_host if for some reason there are any that are defined but not created
18:56:08 melwitt it's not really related to domain start in that domain start will not start them
18:56:20 melwitt the domain will fail to start until you start the nodedev
18:57:05 stblatzheim anyone here who could review and give a +W for the cherrypick for 2023.1 for https://review.opendev.org/c/openstack/nova/+/911070 ?
18:58:28 sean-k-mooney melwitt: well what i was really thinking about is we currenlty undefien an redefine the domain on start so we woudl recreate those i think if you had not already done it in init_host
18:59:30 melwitt sean-k-mooney: oh so colocating it with the domain define/create, yeah I see what you mean
18:59:52 melwitt I thought about that but forgot. I think that would be a good way too
19:00:23 sean-k-mooney im not sure it required but ill try and reject on that when i get aroudn to reviewing properly
19:03:27 melwitt from testing I know that it won't happen on its own but we could definitely add a check + device start before starting the domain
19:04:05 melwitt *won't happen on its own without autostart on the nodedev
19:34:49 sean-k-mooney ack, i think where reasonable we want to try adn get to the point where restarting a compute node does not requrie any manual intervention to sart the vms via the api provided the smi-manage thing is automated via a systemd service or similar before nova starts
19:35:19 sean-k-mooney that means either creating them at init_host, or autostart or at domain start
19:36:41 sean-k-mooney elodilles: would you mined reviewing https://review.opendev.org/c/openstack/nova/+/911070 for stblatzheim when you have time or other stable cores
20:03:40 melwitt sean-k-mooney: I agree. I tested for example creating a nodedev without autostart on purpose, then rebooting the host, then starting the VM. the code in init_host worked to make it so all I had to do was 'server start' (after sriov-manage -e, which I will test with systemd also)
23:50:20 opendevreview Merged openstack/nova master: Update compute rpc alias for caracal https://review.opendev.org/c/openstack/nova/+/912617
#openstack-nova - 2024-03-15
08:22:19 bauzas Uggla: looks to me we're having some problem with your cpu_shared_set series https://review.opendev.org/c/openstack/nova/+/877773
08:22:55 bauzas elodilles: I approved a lot of placement changes this morning, so I'll provide a new revision for the placement RC1 release once all of them are merged
08:23:08 Uggla bauzas, looking at it
08:23:40 bauzas elodilles: for nova, we need to await a bit more, at least the prelude change is not yet approved https://review.opendev.org/c/openstack/nova/+/912973 + I'd like https://review.opendev.org/c/openstack/nova/+/899625/ to be merged
08:23:58 bauzas I know we're late :(
08:24:23 elodilles bauzas: ACK, thanks for the heads up
09:01:25 elodilles sean-k-mooney: LGTM, +2+W'd the patch
09:20:53 Uggla bauzas, found the issue this is _disconnect_volume which is called with 2 more parameters than expected destroy_secrets and force. What is funny that it is the case with the [backport] patch and not with the other.
09:22:33 bauzas cool to know
09:58:58 opendevreview Merged openstack/placement master: Add upgrade job from 2023.1 https://review.opendev.org/c/openstack/placement/+/907742
09:59:00 opendevreview Merged openstack/placement master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/placement/+/911286
09:59:01 opendevreview Merged openstack/placement master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/placement/+/911276
09:59:02 opendevreview Merged openstack/placement master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/placement/+/911296
09:59:04 bauzas \o/
10:00:02 elodilles ~o~
10:00:36 bauzas one last to go, and then I'll update the placement RC1 patch

Earlier   Later