Thursday, 2024-03-14

opendevreviewMerged openstack/nova master: pwr mgmt: handle live migrations correctly  https://review.opendev.org/c/openstack/nova/+/90980600:06
fricklerI see nova is still busy, but is placement ready for rc1? https://review.opendev.org/c/openstack/releases/+/91242707:00
bauzassean-k-mooney: morning, I absolutely forgot about https://review.opendev.org/c/openstack/nova/+/89128908:32
bauzassean-k-mooney: so if you want, we can merge it this morning and then I'll update https://review.opendev.org/c/openstack/nova/+/91261708:34
* bauzas wonders why this change wasn't in https://etherpad.opendev.org/p/nova-caracal-rc-potential#L2608:34
bauzassean-k-mooney: gibi: the SRIOV fix for mdevs is still unapproved, could you please give it a shot ?09:06
bauzashttps://review.opendev.org/c/openstack/nova/+/89962509:06
gibibauzas: I can be the second core there but I need Sean's or Dan's +2 first as I don't have the full context about the discussion here https://review.opendev.org/c/openstack/nova/+/899625/11#message-c3edab5a61f5dfcfc1297e2891ace5d742185f6a09:42
bauzasthis was resolved09:42
gibiI haven't seen Dan's review since that discussion.09:44
bauzascool enough09:47
opendevreviewMerged openstack/nova master: Removed explicit call to delete attachment  https://review.opendev.org/c/openstack/nova/+/89128910:47
opendevreviewSylvain Bauza proposed openstack/nova master: Add a Caracal prelude section  https://review.opendev.org/c/openstack/nova/+/91297311:26
sean-k-mooneybauzas: ack i see https://review.opendev.org/c/openstack/nova/+/891289 is now merged are you going to update https://review.opendev.org/c/openstack/nova/+/91261711:39
sean-k-mooneybauzas: gibi  i readded my +2 but if you want to wait for dan to review that fine too11:47
sean-k-mooneybauzas: ignoring release stuff for a sec i assume your next priority is using the mtty devices to add basic testing in ci of creating instnaces with mdevs11:48
sean-k-mooneyby basic i mean without live migration11:48
sean-k-mooneyout side of perhaps the mdev persitence feature melwitt has in flight and those two bug fixes i really dont want to do anything else realted to mdevs until we have the ci job in place11:51
gibiI +Ad 11:58
gibihttps://review.opendev.org/c/openstack/nova/+/89962511:58
sean-k-mooneyhttps://www.youtube.com/watch?v=ixZpBOxMopc spacex are launching in an hour just an fyi12:00
sean-k-mooneytake 3 at starship12:00
gibiyepp, I following it :)12:01
bauzassean-k-mooney: could you please stop to ask me something when I'm off about 12:30pm ? :)12:19
sean-k-mooneyask you stuff only when your away aroudn 12:30 sure12:20
bauzasanyway thanks for the reviews :)12:20
* bauzas goes off again for my child 12:21
bauzas(for going with her to her school)12:21
artomHuh, https://review.opendev.org/c/openstack/nova/+/877773 somehow avoided the merge conflict14:29
artomWeird, but yey for less work for Uggla 14:29
Ugglaartom, cool, I was about to do it, so it is useless.14:30
sean-k-mooneyartom: it the non backporable one that was in merge conflcit14:34
sean-k-mooneyso ya i guess that my queue to go review the backportable one14:35
artomThey're both apparently clear14:35
artomNot sure how14:35
sean-k-mooneyoh its says same topic not merge conflict 14:35
sean-k-mooneyartom: are your patches emged now14:35
sean-k-mooneyi tought several of them were still pending14:36
artomYeah, they all went through last night14:36
sean-k-mooneyin that case would you mind starting the backport of your patches14:37
artomYep14:44
artomTo Antelope, right? When did we actually add power management?14:44
artomYeah https://specs.openstack.org/openstack/nova-specs/specs/2023.1/implemented/libvirt-cpu-state-mgmt.html14:45
sean-k-mooneyyes 14:46
sean-k-mooneyUggla: change choudl go back futher but antelope would be ok for that too14:47
sean-k-mooneyzed will move to unmainteined in a few weeks14:47
artomWe'd like it downstream in 17.1 though14:48
sean-k-mooneybasically when the offial release of caracal happens in april14:48
sean-k-mooneywe can optionally propose it to the unmained branches if we like14:48
sean-k-mooneyassuming that helps with the downstream backprot withc it likely will14:49
sean-k-mooneyjust saying that by default the stable/core team are not expected to do backports to unmaintained/*14:49
opendevreviewArtom Lifshitz proposed openstack/nova stable/2023.2: Add cpuset_reserved helper to instance NUMA topology  https://review.opendev.org/c/openstack/nova/+/91319314:57
opendevreviewArtom Lifshitz proposed openstack/nova stable/2023.2: Reproducer for not powering on isolated emulator threads cores  https://review.opendev.org/c/openstack/nova/+/91319414:57
opendevreviewArtom Lifshitz proposed openstack/nova stable/2023.2: Power on cores for isolated emulator threads  https://review.opendev.org/c/openstack/nova/+/91319514:57
opendevreviewArtom Lifshitz proposed openstack/nova stable/2023.2: pwr mgmt: make API into a per-driver object  https://review.opendev.org/c/openstack/nova/+/91319614:57
opendevreviewArtom Lifshitz proposed openstack/nova stable/2023.2: Reproducer test for live migration with power management  https://review.opendev.org/c/openstack/nova/+/91319714:57
opendevreviewArtom Lifshitz proposed openstack/nova stable/2023.2: pwr mgmt: handle live migrations correctly  https://review.opendev.org/c/openstack/nova/+/91319814:57
opendevreviewArtom Lifshitz proposed openstack/nova stable/2023.1: fup for power management series  https://review.opendev.org/c/openstack/nova/+/91322115:08
opendevreviewArtom Lifshitz proposed openstack/nova stable/2023.1: Add cpuset_reserved helper to instance NUMA topology  https://review.opendev.org/c/openstack/nova/+/91322215:08
opendevreviewArtom Lifshitz proposed openstack/nova stable/2023.1: Reproducer for not powering on isolated emulator threads cores  https://review.opendev.org/c/openstack/nova/+/91322315:08
opendevreviewArtom Lifshitz proposed openstack/nova stable/2023.1: Power on cores for isolated emulator threads  https://review.opendev.org/c/openstack/nova/+/91322415:08
opendevreviewArtom Lifshitz proposed openstack/nova stable/2023.1: pwr mgmt: make API into a per-driver object  https://review.opendev.org/c/openstack/nova/+/91322515:08
opendevreviewArtom Lifshitz proposed openstack/nova stable/2023.1: Reproducer test for live migration with power management  https://review.opendev.org/c/openstack/nova/+/91322615:08
opendevreviewArtom Lifshitz proposed openstack/nova stable/2023.1: pwr mgmt: handle live migrations correctly  https://review.opendev.org/c/openstack/nova/+/91322715:08
bauzasartom: sean-k-mooney: yeah, I'll look at the backports after GA15:09
bauzas(Apr 03)15:09
artombauzas, sean-k-mooney, I'll cherry-pick them downstream anyways15:10
bauzassure, but please don't discuss downstream usage here :)15:10
bauzasit's a public channel 15:10
bauzas(and we log everything :) )15:10
sean-k-mooneythis is entirly approate to disucss here15:11
bauzassean-k-mooney: gibi: dansmith: https://review.opendev.org/c/openstack/nova/+/912973 prelude is open for reviews 15:11
sean-k-mooneyartom was askign if we shoudl consider backportign to unmaintend branhces15:11
sean-k-mooneyand i say we can do that if we want to for other reasons15:11
sean-k-mooneybut form a core or stable core perspective we do not maintian those15:11
sean-k-mooneyand are not expected to do backport to them15:11
artomI don't think it's a surprise that Red Hat has a downstream product, and that we do cherry-picks :)15:11
artomIt's not like we're discussing downstream-only code changes here15:12
sean-k-mooneyright so i was just trying to provide guidence that we shoudl default to backporting to stable/*15:12
artomOh, totally15:12
sean-k-mooneyand unmaintained/* is optional but not expected15:13
artomAs far back as is reasonably possible.15:13
artomYep.15:13
sean-k-mooneyif we are backporting downstream past stable/* it does not hurt to provide the patches publicly but if peopel choose not to it that ok too15:13
sean-k-mooneyi 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 default15:14
bauzasfor sure15:19
bauzasI was just saying to make sure we don't need to discuss about our downstreack backports here15:19
bauzasnot because of security, but rather Red Hat is not the only company working upstream :)15:20
sean-k-mooneyyep i just wanted artom to start on the upstream one and we can figure out downsteam when wever that becomes relevent15:20
bauzas(and it was just a reminder that we log everything here : https://meetings.opendev.org/irclogs/%23openstack-nova/ )15:21
artomsean-k-mooney, they're all posted anyways, even the downstream ones :)15:21
* bauzas needs to get his child back from the school, I'll be back in 20 mins15:22
artombauzas, 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 discussed15:22
bauzasno worries, but maybe not all of us know about the logs :) )15:23
sean-k-mooneyi do and im sure artom does so is it new info to you?15:24
artomI was totally about to post by credit card PIN15:25
sean-k-mooneypassword:15:25
sean-k-mooney:)15:25
sean-k-mooneyanyway i got distracted by thing ill go back and review Uggla patch now15:26
artomSee, then you typed your password, I saw *****, but you saw hunter2, because IRC is smart like that15:32
opendevreviewSylvain Bauza proposed openstack/nova master: Update compute rpc alias for caracal  https://review.opendev.org/c/openstack/nova/+/91261715:59
bauzasdansmith: gibi: sean-k-mooney: yet another paperwork change for RC1 ^16:00
bauzas(just updated it b/c of the new RPC version we just added)16:00
sean-k-mooneyack im +2 on https://review.opendev.org/c/openstack/nova/+/877773 by the way16:03
gibiI'm +2 the RPC alias16:20
bauzaselodilles: 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:open17:04
bauzashttps://review.opendev.org/c/openstack/placement/+/907742 seems at least nice to have17:04
sean-k-mooneythe slurp job can merge at any point17:23
sean-k-mooneywe can trivially just backport that to the stable branch17:23
sean-k-mooneybut i agree it woudl be nice to have17:23
elodillesbauzas: ACK, thanks for signaling it on the release patch!17:49
elodilles(though you linked a nova patch there o:))17:49
melwittsean-k-mooney: speaking of persistent mdevs, I think it's ready for review if you were wondering https://review.opendev.org/c/openstack/nova/+/91004118:37
sean-k-mooneyhow did testing host reboot go. were you able to do it with the sytemd service file?18:38
sean-k-mooneymelwitt: this is for dalmation ya so i can try and review it but we need to wait for RC1 to ship before merging i guess18:40
sean-k-mooneythis 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 perpwective18:41
melwittsean-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 on18:41
sean-k-mooneycool18:41
melwittsean-k-mooney: I didn't think to try the systemd way for some reason. I only did it manually. I'll try systemd next18:42
melwittI did remember to put the systemd mention into docs/ in that patch 😛 18:42
sean-k-mooneyack if your including the doc update with the systemd script then ya it would be good to test that locally18:42
sean-k-mooneyyep its teh second ting i read after the commit message18:43
melwittyeah. agree18:43
sean-k-mooneyoh i see your supproting eithe rway based on the libvirt version18:45
melwittyeah.. initially I didn't do that but realized it later. we would need a min version bump to not have to do it I think18:46
sean-k-mooneyam that will not strictly be required as we can move to libvirt 8.0.0 next cycle 18:46
sean-k-mooneybut since you have it working we can keep it18:46
melwittwhich we might be doing for dalamation, so I can take that out if so18:46
melwittit would make the change much prettier if we bumped to 8.0.0 heh18:47
sean-k-mooneyya although its not terrible as is18:47
melwittpersistent mdevs in 7.3.0 and autostart in 7.8.018:47
sean-k-mooneyautostart in this context being create them automatically on host start right18:48
sean-k-mooneyrather then domain start18:48
sean-k-mooneymay be worth adding follow up patches that do the min bump18:49
sean-k-mooneyand we can then defer that choice until we decied if we bump to 8.0.018:49
sean-k-mooneyit looks like there would not actully be much clean up to do fo 8.0.018:50
sean-k-mooneyi mean for other feature18:51
sean-k-mooneyall the feature gates seam to be 8.y.z18:52
sean-k-mooneyso i dont think you will need to do much cleanup if you decied to creat that patch18:52
melwittsean-k-mooney: yes autostart is the virNodeDeviceCreate happening automatically at host start18:55
melwittI also added a thing to do it during init_host if for some reason there are any that are defined but not created18:55
melwittit's not really related to domain start in that domain start will not start them18:56
melwittthe domain will fail to start until you start the nodedev18:56
stblatzheimanyone here who could review and give a +W for the cherrypick for 2023.1 for https://review.opendev.org/c/openstack/nova/+/911070 ?18:57
sean-k-mooneymelwitt: 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_host18:58
melwittsean-k-mooney: oh so colocating it with the domain define/create, yeah I see what you mean18:59
melwittI thought about that but forgot. I think that would be a good way too18:59
sean-k-mooneyim not sure it required but ill try and reject on that when i get aroudn to reviewing properly19:00
melwittfrom testing I know that it won't happen on its own but we could definitely add a check + device start before starting the domain19:03
melwitt*won't happen on its own without autostart on the nodedev19:04
sean-k-mooneyack, 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 starts19:34
sean-k-mooneythat means either creating them at init_host, or autostart or at domain start19:35
sean-k-mooneyelodilles: would you mined reviewing https://review.opendev.org/c/openstack/nova/+/911070 for stblatzheim when you have time or other stable cores19:36
melwittsean-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)20:03
opendevreviewMerged openstack/nova master: Update compute rpc alias for caracal  https://review.opendev.org/c/openstack/nova/+/91261723:50

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!