Friday, 2021-09-24

opendevreviewmelanie witt proposed openstack/nova master: WIP Enable unified limits in the nova-next job  https://review.opendev.org/c/openstack/nova/+/78996300:26
*** akekane_ is now known as abhishekk05:23
fricklergood morning nova, it seems you are running the l-c job in gate as non-voting, which doesn't make sense to me, see e.g. https://review.opendev.org/80995506:27
*** rpittau|afk is now known as rpittau06:41
bauzasgood Friday, Nova07:31
bauzasfrickler: tell me, we had issues with this job due to some dep07:31
bauzasfrickler: saw the mailing thread from gibi ? can find it if you want07:32
bauzasactually, the problem is on placement, not nova07:36
elodilleswell, the problem is there in several projects07:39
bauzaselodilles: I don't disagree07:40
elodillesbauzas: good to hear that :)07:40
bauzasbut I'd somehow appreciate that we could only make the job non-voting only when needed07:40
bauzasfor nova, ussuri and later provide decorator>=4.0.007:40
elodillesand nova has it too in ussuri and older branches07:40
bauzasoh, strange https://github.com/openstack/nova/blob/stable/ussuri/lower-constraints.txt#L2107:41
bauzasoh shit07:41
bauzas22 to 24 is 3 releases07:41
bauzasxena being the 24th, ussuri is 4 releases older07:42
bauzasI forgot about victoria :D07:42
bauzasprobably the effect of not having the PTG physically located for the first time :)07:42
elodillesanyway, gibi has a solution, which actually solves the situation: https://review.opendev.org/c/openstack/nova/+/81046107:42
elodillesmaybe we should use that one directly and not merge the 'set l-c as non-voting' patch (which meant to be as 'temporary')07:43
bauzasmaybe07:44
gibimorning08:01
kashyaplyarwood: Morning; that error about "Could not allocate dynamic translator buffer" -- I recall seeing it in the past (in OpenStack CI) -- it was due to out-of-memory mostly08:10
lyarwoodACK, just getting my haircut now, I'll look again at the memory tracking log in the job when I get back08:30
kashyapHave a good one08:40
bauzasgibi: does that ring a bell to you if I say that when the virt driver returns a list of inventories, we don't remove the existing RPs that are no longer used ?09:24
bauzascontext : https://bugs.launchpad.net/nova/+bug/194403109:24
bauzashmmmm, looking at https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L822609:25
bauzaswe update the provider tree09:26
bauzasbut I guess if we have resource providers, we don't verify whether they're still used09:26
* bauzas needs to disappear for going to the gym09:37
opendevreviewPierre Riteau proposed openstack/nova master: Create empty pcpuset for unpinned instances  https://review.opendev.org/c/openstack/nova/+/81084909:47
gibibauzas: hm, it could be that we never had to delete any RP before VGPU move to its own RP10:11
gibifrom nova-compute10:11
gibiso we might missed that case10:11
opendevreviewBalazs Gibizer proposed openstack/nova master: Reproduce bug 1944759  https://review.opendev.org/c/openstack/nova/+/81076311:06
*** bhagyashris is now known as bhagyashris|rover11:09
opendevreviewStephen Finucane proposed openstack/nova master: tests: Walk database migrations in correct order  https://review.opendev.org/c/openstack/nova/+/81029111:14
opendevreviewStephen Finucane proposed openstack/nova master: db: Add migration to resolve shadow table discrepancies  https://review.opendev.org/c/openstack/nova/+/80573811:14
opendevreviewStephen Finucane proposed openstack/nova master: tests: Address some nits with database migration series  https://review.opendev.org/c/openstack/nova/+/81085611:14
opendevreviewStephen Finucane proposed openstack/nova master: tests: Silence noise from database tests  https://review.opendev.org/c/openstack/nova/+/81085711:14
opendevreviewLee Yarwood proposed openstack/nova master: Add check job for FIPS  https://review.opendev.org/c/openstack/nova/+/79051911:41
gibisean-k-mooney: do you remember where we are with mixing numa aware live migration with sriov live migration? Does src_compute(PF-numa0) -> dest_compute(PF-numa1) works?12:05
gibiI do remember that we had issues but I don't if we solved them or just punted them for later12:05
gibiand I only have lab nodes where both PF on numa1 so I cannot test it12:06
sean-k-mooneygibi: yes it should12:10
sean-k-mooneyalthough most of the testing i did was with nic that did not report numa affinity12:10
sean-k-mooneybut i did force cross numa migration viat the cpu_dedicated_set and test that with sriov12:11
sean-k-mooneybut i would have been using the prefer policy effectivly by relaying on the fact my nics did not report numa affinity12:12
sean-k-mooneygibi: you can try testing it with the prefer policy in your case12:12
sean-k-mooneythe ohter way to test it is technially the numa filed in /sys is writable12:13
gibihm, interesting :D12:13
sean-k-mooneyso if you echo 0 into the file and restart libvirt ...12:13
sean-k-mooneyi have done that in the past to fake it too with my hardware12:13
gibiOK, I can try that, thanks for the idea12:13
opendevreviewLee Yarwood proposed openstack/nova-specs master: Repropose flavour and image defined ephemeral storage encryption  https://review.opendev.org/c/openstack/nova-specs/+/81086712:14
opendevreviewLee Yarwood proposed openstack/nova-specs master: Repropose Add libvirt support for flavor and image defined ephemeral encryption  https://review.opendev.org/c/openstack/nova-specs/+/81086812:14
sean-k-mooneygibi: since i have you have you seen nova.exception.PortNotUsable: Port 123c94fa-a71a-48c1-9195-ec2a1d6d2f40 not usable for instance 36441284-b272-439d-b8cf-f7c62efc9151. before12:15
gibihm I saw but I have to dig, I think there are multiple reasons for that12:15
sean-k-mooneyi must have been lucky to never hit it till now12:16
sean-k-mooneyim currently trying to test vdpa with ovn12:16
gibione reason is that the port is in a different project than the instance12:16
sean-k-mooneyill dig into it on the neutron side and see whats going on12:16
gibinova explicitly checks that12:16
sean-k-mooneyit is failing in _validate_requested_port_ids so maybe12:17
gibihttps://github.com/openstack/nova/blob/c8940f9d60f1b0290ebea94fb6174efac9a1632e/nova/network/neutron.py#L73712:17
gibiyepp that will be it12:17
sean-k-mooneyyep https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L736-L73812:17
sean-k-mooneyya ok prot is owned by demo and vm is owned by admin12:19
sean-k-mooneyok so horrizon does not work with vdpa ports12:19
sean-k-mooneythey dont show up in the port list in the instance create as demo12:20
sean-k-mooneymaybe i shoudl just recreated it and test this form the cli12:20
sean-k-mooneyoh active  :)12:22
sean-k-mooneyi was not expecting that :P12:22
opendevreviewPierre Riteau proposed openstack/nova master: Create empty pcpuset for unpinned instances  https://review.opendev.org/c/openstack/nova/+/81084912:31
bauzasgibi: I guess we would have the same concern (deleting old and not used RPs) for vpmems, nope ?13:06
gibivpmems has its own RP?13:08
gibior is it tracked on the compute RP?13:08
opendevreviewsean mooney proposed openstack/nova master: [DMN] test removal of CAP_DAC_OVERRIDE  https://review.opendev.org/c/openstack/nova/+/81090613:21
bauzasgibi: my bad, those are just inventories from the same RP13:22
sean-k-mooneygibi: i think its on the compute node currently13:22
gibiyepp that what was I assumed13:22
bauzassean-k-mooney: yeah, https://github.com/openstack/nova/blob/62406b5728077afa9cd38d5c5d510bba64c43bd7/nova/virt/libvirt/driver.py#L837913:22
sean-k-mooneywith 1 inventory per namespace13:22
sean-k-mooney*namespace size13:22
bauzasthen, maybe bandwidth-aware resource providers could be impacted or is that only a VGPU thing ?13:23
bauzasactually, this doesn't come from the virt driver13:23
gibibauzas: bwm RPs are managed by neutron agents13:23
bauzasyeah13:23
sean-k-mooneywhat are you currently talking about by the way13:23
bauzasso I guess this is maybe unrelate13:23
gibito be precies RP and inventory is managed by neutron, allocation managed by nova13:23
bauzassean-k-mooney: https://bugs.launchpad.net/nova/+bug/194403113:24
sean-k-mooneyfor bandwith and pps inventories?13:24
gibisean-k-mooney: https://bugs.launchpad.net/nova/+bug/194403113:24
bauzasshoooooot13:24
sean-k-mooneyah right that13:24
sean-k-mooneywell for things on the root rp its simple to fix13:24
sean-k-mooneyfor nested RPs without an owner trait on the RP its harder13:25
sean-k-mooneye.g. if RP had ownwer_nova and its not in the tree nova just compute then it should be removed13:25
sean-k-mooneywithout that its very hard to figure out it the RP is owned by nova or by cyborg/neutorn13:25
sean-k-mooneyif vgpus were tracked in the db we woudl also have another way to figure this out but since we dont have them in the resouce table or pci_devices table13:27
sean-k-mooneywe cant use the nova db to determin if it was an rp we created13:27
bauzassean-k-mooney: yeah tbh, I think it should be the responsibility of the virt driver to compare the provider tree before and after the update and eventually remove unused RPs13:27
sean-k-mooneybauzas: it should but we dont have the info in placment to be able to do that correctly today13:27
bauzassean-k-mooney: this could be done in https://github.com/openstack/nova/blob/62406b5728077afa9cd38d5c5d510bba64c43bd7/nova/virt/libvirt/driver.py#L847213:28
sean-k-mooneybauzas: not today13:28
bauzasof course13:28
bauzasbut we have the actual state in provider_tree13:28
sean-k-mooneybauzas: you can know if the nested RP is own by neutron or cyborg13:29
bauzasthat's given 13:29
sean-k-mooneyso it not safe to remove it13:29
bauzassean-k-mooney: we namespace the RPs13:29
sean-k-mooneywe do not13:29
gibiwhat we can do is to assume that if the RP had VGPU inventory before then it is owned by nova13:29
bauzasfor GPUs ? we totally do13:29
gibi:)13:29
gibior we use the name of the RP13:30
sean-k-mooneygibi: only if we intend to make it so cyborg cannot use the vgpu inventory type13:30
bauzasthe problem is that this naming could be used by *something else*13:30
bauzasbut if we consider that https://github.com/openstack/nova/blob/62406b5728077afa9cd38d5c5d510bba64c43bd7/nova/virt/libvirt/driver.py#L8505 is only used by the virt driver, then you can look at all existing RPs matching this13:31
sean-k-mooneyany resilance on nameing or RC usage is fragile13:31
gibiyep it is fragile I agree13:31
bauzasagreed tho13:31
gibiRP naming is a bit better than RC I think13:31
gibiso fixing this as a bug I would go with relying on RP naming13:32
sean-k-mooney if we prefixed them all with nova_ then i would strongly agree13:32
sean-k-mooneyfight now however we may have collitions although its unlikely13:32
sean-k-mooney*right13:32
sean-k-mooneygibi: as a bug fix using the name template13:32
sean-k-mooneywould proably be ok if we implement a proper solution in yoga13:32
bauzashonestly, operators are not intended to change their config everyday13:33
sean-k-mooneye.g. in nova prefix all nova RPs with nova_ or add a mapping table in our db where we store the uuids of all RPs we own13:33
gibisean-k-mooney: yeah, thinking about it in Yoga PTG would be a good first step13:34
bauzaswe could somehow use the audit command to find the orphaned RPs13:34
sean-k-mooneya nova manage command ya would work13:34
bauzasit would have my preference honestly13:34
sean-k-mooneyusing osc they can also fix it today13:34
sean-k-mooneyvia osc-placment13:34
bauzassure, hence the low13:34
bauzasthe low status I mean13:34
bauzasthis is absolutely not a problem 13:34
bauzasthis is just, you're creating garbage13:35
sean-k-mooneywell it can break schduling13:35
sean-k-mooneyso it can be a problem13:35
bauzasgive me a sec, verifying the inventories13:35
sean-k-mooneybut we do not nessisaly need to automically fix it if we provide a tool to do it when you change the config13:35
sean-k-mooneygibi: just an fyi im on PTO next week just in case your looking for me13:36
bauzashmmm, you're right13:36
bauzasinventories are left13:36
bauzas[root@hab-19 devstack]# openstack resource provider inventory list 7853e09b-5f5c-4b79-99c6-a550c56eb7e013:36
bauzas+----------------+------------------+----------+----------+----------+-----------+-------+------+13:36
bauzas| resource_class | allocation_ratio | min_unit | max_unit | reserved | step_size | total | used |13:36
bauzas+----------------+------------------+----------+----------+----------+-----------+-------+------+13:36
bauzas| VGPU           |              1.0 |        1 |        1 |        0 |         1 |     1 |    0 |13:36
bauzas+----------------+------------------+----------+----------+----------+-----------+-------+------+13:36
bauzasdammit13:36
gibisean-k-mooney: thanks for the heads up, enjoy your time off13:36
bauzasso instances could pick those resources13:37
sean-k-mooneybauzas: ya the inventories would because when you remove the confi the virt driver will just not update the rp or its inventories again13:37
bauzasyup13:37
sean-k-mooneythis is also a problem for provider.yaml by the way13:37
sean-k-mooneyif we remove something form provider.yaml it will never get removed form placment13:37
bauzasdefinitely worth a PTG discussion then13:38
sean-k-mooneybauzas: we could perhaps write a file to disk in the nova state dir13:38
bauzassean-k-mooney: fancy adding a 10th bullet point or want me to write it ?13:38
bauzasI mean, I couldf13:38
sean-k-mooneythat way the agent could read it on start up and use that to figure out if something was removed13:38
sean-k-mooneyif we did not want to store it in the db13:39
sean-k-mooneybauzas: am i can i guess i have another to add anyway13:39
opendevreviewBalazs Gibizer proposed openstack/nova master: Store old_flavor already on source host during resize  https://review.opendev.org/c/openstack/nova/+/81090913:39
sean-k-mooneyjust assume the stuff i add is an aggreate of stuff we have mentioned in downstream or upstream meetings/discussions13:39
gibibauzas, sean-k-mooney: I will check what today's neutron does if I remove the bw config. I guess we have the same missing cleanup problem in neutron too. If we have, then I would argue for a solution that is not nova specific or at least easy to apply to neutron too13:42
bauzasgibi: that's why a audit tool seems important13:44
bauzasbut the working logic is owned by neutron or the virt driver13:44
bauzasso I don't know how a tool could be prescriptive13:45
gibibauzas: RP cleanup is OK to be left for the nova-manage but inventory cleanup is needed to be automatic to avoid wrong scheduling13:45
bauzasagreed13:45
bauzasand RP cleanup would be easily manageable in the audit command13:46
bauzasif inventories are left empty13:46
gibiyepp13:47
gibino inventory is a good indication to a RP to be deleted13:47
gibithere are exceptions though :D13:48
gibia neturn sriov agent without any PF configured13:48
gibicreates an agent RP and no PF RPs13:48
gibibut the agent RP has no inventory13:48
gibiso the audit tool would delete it13:48
gibithen neutron would re-create it :D13:48
gibithere is no harm, just noise13:48
gibiand having an sriov agent without any PF is a pretty useless config :D13:49
gibibtw if we have a proper logic to null out inventory on an RP then the agent nulling out the last inventory could delete the RP automatically too13:50
opendevreviewBalazs Gibizer proposed openstack/nova stable/xena: Reproduce bug 1944759  https://review.opendev.org/c/openstack/nova/+/81091013:50
opendevreviewBalazs Gibizer proposed openstack/nova stable/xena: Store old_flavor already on source host during resize  https://review.opendev.org/c/openstack/nova/+/81091113:50
opendevreviewBalazs Gibizer proposed openstack/nova stable/wallaby: Reproduce bug 1944759  https://review.opendev.org/c/openstack/nova/+/81091213:53
gibione less escalation ^^13:53
gibiI'm pushing this back to victoria without delay as I need this upstream on victoria13:54
opendevreviewBalazs Gibizer proposed openstack/nova stable/wallaby: Store old_flavor already on source host during resize  https://review.opendev.org/c/openstack/nova/+/81091313:54
opendevreviewBalazs Gibizer proposed openstack/nova stable/victoria: Reproduce bug 1944759  https://review.opendev.org/c/openstack/nova/+/81091413:56
opendevreviewBalazs Gibizer proposed openstack/nova stable/victoria: Store old_flavor already on source host during resize  https://review.opendev.org/c/openstack/nova/+/81091513:56
sean-k-mooneyi added two more itmes to the ptg adgenda14:00
* sean-k-mooney planned to not have any this cycle...14:00
sean-k-mooneylines 182 for the inventory cleanup https://etherpad.opendev.org/p/nova-yoga-ptg14:01
gibisean-k-mooney: thanks!14:01
sean-k-mooneycan you update that with what you find for neturon14:02
gibisure14:02
gibiI will do that today14:02
sean-k-mooneyno rush we have time before the ptg14:03
sean-k-mooneybauzas: speaking of which i assuem you are going to take the etherpad and turn it into an adgenda at some point14:04
gibisean-k-mooney: I just closed an escalation I have a lot of motivation :D14:04
sean-k-mooneythats alwasy a nice feeling espically on a friday14:05
sean-k-mooneygibi: by the way i have only been skimming what happing with setuptool. are we any closer to a decision on what to do for the stable branches14:05
bauzassean-k-mooney: yup will work on it 14:07
bauzas(the agenda)14:07
* bauzas needs to dogwalk for getting her kid from school14:07
gibisean-k-mooney: I have a solution based on you idea of [tox]requires config that proved to be working. It seems others are more for dropping lower constraints testing althogheter which is fine by me. 14:07
gibisean-k-mooney: however a recent mail might means that we have the same issue outside of lower constraint testing http://lists.openstack.org/pipermail/openstack-discuss/2021-September/025040.html14:08
sean-k-mooneyok and are we going to look into the project.yaml or what ever the new thing is for yoga on?14:08
gibipyproject.yaml is the thing but honestly I has not time to look into that as a direction14:08
gibiI assume it also needs some common agreement in OpenStack 14:09
sean-k-mooneyya we proably should not be using any deps that rely on use_2to3 realistically in ussuri14:09
sean-k-mooneygibi: yep we would14:09
sean-k-mooneyit would fundemtally change how we do dep managment14:09
sean-k-mooneyits a replacment for requirements.txt and tox.ini all wrapped into one file14:09
sean-k-mooneyi think it can still use the other but its basically one file to rule them all14:10
gibiOK then it is definitely bigger that I can chew right now14:12
sean-k-mooneyyep it is14:13
gibiand it is Friday :)14:15
priteauHello. Who has rights to update the Nova bug template on LP? I noticed an issue with the rpm command.14:17
priteauSee https://wiki.openstack.org/wiki/Nova/BugsTeam/BugReportTemplate14:17
priteau`rpm -ql | grep <projectname>` should be `rpm -qa | grep <projectname>`14:17
gibipriteau: I think anybody can edit the wiki I'm not sure about LP14:18
priteauI can make the wiki edit of course, but what matters is syncing with LP ;-)14:19
gibipriteau: I found I can update the LP14:19
gibilet me know what needs to be fixed and I will do it in LP14:20
gibiahh I see what is needed14:20
priteauI've updated the wiki page14:20
gibihm, do we need both -a and -l ?14:21
gibiis -l a shortcut for --last ?14:23
gibi(I'm on debian :D)_14:23
sean-k-mooneywe  proably should jsut remove it from the template14:23
sean-k-mooneyi think for deb packages -l is for list14:23
sean-k-mooneyi can check14:23
priteauJust -qa14:24
priteau-ql is for listing files inside a package14:24
priteau       -l, --list14:24
priteau              List files in package.14:24
gibiohh OK then -a it is14:24
gibifixed the LP 14:24
gibipriteau: thanks for reporting it14:24
sean-k-mooneyyes -qa14:24
sean-k-mooneybut really we dont care about the package version most of the time we just care about the openstack version14:25
priteauThis is an easy way to find the version when using binary packages14:25
sean-k-mooneywe care for libvirt and qemu sometimes but we porably could make it more generic 14:26
sean-k-mooneypriteau: right but upstream that normally not useful14:26
sean-k-mooneysince we cant easially map it to the source code14:26
sean-k-mooneyeven downstream the pacakge version is not very useful since that mapping is hard to do 14:27
sean-k-mooneywe often have to pull the srouce rpm and check if a patch is in it which is a pain14:27
sean-k-mooneypriteau: by the way the template also tells you to run udo sosreport -o openstack_nova --batch14:29
sean-k-mooneywhich i dont think i have ever seen peopl actully do14:29
priteauWho follows instructions? :)14:29
priteauWould you like people to use `pip3 list | grep nova` as an alternative?14:29
sean-k-mooneynot nessisarly but its helpful if they clearly state that they used train or the serise name14:30
opendevreviewLucian Petrut proposed openstack/nova master: api: enable oslo.reports when using uwsgi  https://review.opendev.org/c/openstack/nova/+/81092214:30
sean-k-mooneyknowing the disto and or package version is nice too14:30
priteauI imagine knowing the release tag can be quite useful14:32
opendevreviewLucian Petrut proposed openstack/nova master: api: enable oslo.reports when using uwsgi  https://review.opendev.org/c/openstack/nova/+/81092214:32
gibijust yesterday I troubleshooted a deployment with nova_compute version 22.2.3 :D14:32
lpetruthi, I'm hitting some nova api deadlocks and noticed that oslo.reports isn't enabled when using uwsgi so I've submitted a small commit: https://review.opendev.org/c/openstack/nova/+/81092214:33
gibi(note that we only released 22.2.2 upstream)14:33
sean-k-mooneygibi: ya i was going to say was this in the gate :)14:33
sean-k-mooneycause otherwise they are going to have fun when we do the next stable release14:34
gibisean-k-mooney: it was downstream. I think what they did is they took what was unreleased from stable/victoria and created 22.2.3 out of it downstream14:34
sean-k-mooneyi see14:35
gibiwhich is problematic as you said14:35
gibilpetrut: seems useful14:35
gibilpetrut: thanks14:35
sean-k-mooneyhuh 14:36
sean-k-mooneymaybe that is why the GMR were not working instead of what we tought with the signal being intercpted by uwsgi/mod_wsgi14:37
gibisean-k-mooney: or we need both :)14:37
sean-k-mooneylpetrut: i assume you tested this and it logs the GMR to the log properly on kill -usr214:37
sean-k-mooneygibi: ya i was wonderign if that would only work if you set the signal to the python interpreter instnace14:38
gibiunfortunately this is pretty complicated to test upstream. 14:39
lpetrutsean-k-mooney: the signal still gets intercepted but I'm using a file listener14:39
gibiI mean automatically testing it14:39
sean-k-mooneylpetrut: intercepted by uwsgi and not passed to nova right14:39
sean-k-mooneylpetrut: oh are you poking a file to trigger it14:40
sean-k-mooneyinstead of sig_usr2 or soemthing14:40
lpetrutyep, I'm setting something like oslo_reports.file_event_handler = /opt/stack/logs/trigger14:40
sean-k-mooneygibi: we could proably add a func test but we would have to expand the test scope14:40
sean-k-mooneylpetrut: ok i dont think we technially support that in nova14:40
sean-k-mooneybut it certenly works around the issue14:41
lpetrutit already works with most nova services, they key is to pass the config when calling the gmr hook14:41
sean-k-mooneyso this is really a mini feature rather then a bug14:41
gibisean-k-mooney: do we run nova-api in uwsgi in func test? 14:41
sean-k-mooneygibi: no but we coudl do somehting like neutorn fullstack tests14:41
gibisean-k-mooney: ack, that is a possibility14:42
sean-k-mooneyit would be a different type of test14:42
gibisean-k-mooney: or add this to nova-next post test hook 14:42
sean-k-mooneygibi: ya that too14:42
gibibauzas, sean-k-mooney: btw I confirm that neutron also leaks inventories if the bw or pps config is removed 14:43
sean-k-mooneylpetrut: did you want to backport udo sosreport -o openstack_nova --batch14:43
sean-k-mooney* https://review.opendev.org/c/openstack/nova/+/810922/2/nova/api/openstack/wsgi_app.py14:43
sean-k-mooneyto me this is really a specless blueprint 14:43
sean-k-mooneyso not something we woudl backport14:43
sean-k-mooneyi think its a nice change to merge so no real objection to the patch14:44
sean-k-mooneyjust not sure this is a bug and a spec is way to heavy weight so not sure how to track this14:45
sean-k-mooneyto me its really just a trivial fix but it proably should have a release note14:45
lpetrutyeah, it's hard to label it as a bug in order to allow backports but that's ok. a release note makes sense, I can also mention the fact that uwsgi may intercept SIGUSR2, in which case a file trigger may be configured14:46
sean-k-mooneylpetrut: ya if you add a release note and maybe add a doc for the intercept i would be +1 on it14:47
lpetrutawesome, thanks. is there a specific doc that you have in mind?14:48
sean-k-mooneywe have a doc for GMR i think in the contibutor section 14:48
sean-k-mooneyhttps://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/doc/source/reference/gmr.rst14:49
sean-k-mooneyah its in refernce14:49
sean-k-mooneycan you update https://github.com/openstack/nova/blob/master/doc/source/reference/gmr.rst#generating-a-gmr14:49
sean-k-mooneywith the exmaple of the file trigger14:50
lpetrutdefinitely, thanks for the link14:50
lpetrutthe "TextGuruMeditation.setup_autorun(version)" hook sample should also be updated. if we don't pass the config, gmr will not be aware of the [oslo_reports] config opts14:51
sean-k-mooneyya i dont think we have really updated it since it was added14:56
sean-k-mooneyi would suggest updating the existig singal based exmaple to use nova-compute and then adding the file example for nova-api and makeign any other changes that you think are needed14:57
lpetrutsounds good14:59
*** yonglihe_ is now known as yonglihe15:08
bauzasgibi: ack, so we need to discuss this during the PTG15:15
gibiyepp15:15
gibiadded notes to the bad15:15
gibipad15:16
lpetrutone minor nit: gmr.setup_autorun takes a "service_name" parameter which is used when constructing the report filename. when missing, it's trying to retrieve it from the stack trace but it seems to always end up with "thread.py", so the reports are named something like "thread.py_gurumeditation_20210924141722". since none of the other service pass this parameter, I'm thinking about doing the same for nova-uwsgi for consistency reasons.15:16
sean-k-mooneylpetrut: or you could fix them all15:19
sean-k-mooneylpetrut: you should be able to use the service binary name15:20
sean-k-mooneyso  service_obj.binary15:20
lpetrutthat works as well15:20
sean-k-mooneythat way if you have multiple service on the same host using the same file tirrger they wont overright15:21
sean-k-mooneyalthough the timestamp is unlikely to collide in anycase15:21
lpetrutright, it's also more user friendly since it's easier to tell which is the originating service15:24
sean-k-mooneywell when not using the file backend it dumps to the service log so that not been an issue before but for dumping the GMR to a file its something we shoudl definetly address15:25
gibisean-k-mooney: btw, I tried your echo 0 > numa_node  trick and it works like a charm. I can now confirm that live migration with SRIOV + NUMA works and the numa topology is properly recalculated 15:41
sean-k-mooneythats an old trick i have been using for ever 15:44
gibithis knowledge is gold15:45
sean-k-mooneyif you ignore the horrible hack that it is you can actully write udev rules to allwo you to assocaite the device with other numa nodes on the same socket if you enabel cluster on die or amds numa_per_socket>115:48
opendevreviewLucian Petrut proposed openstack/nova master: api: enable oslo.reports when using uwsgi  https://review.opendev.org/c/openstack/nova/+/81092215:48
sean-k-mooneyok going to finish there o/ talk to ye in a week15:55
fungielodilles: has there been any progress on discussions of whether to discontinue lower-constraints jobs on nova's stable/ussuri branch? at this point, nothing (including an outstanding security fix) can merge there, so it's probably time to start talking about early eol instead16:36
fungiat least if we're up front with users that we're no longer fixing known vulnerabilities on that branch, the vmt can go forward with announcing fixes on the nova branches which are still receiving patches16:37
*** tbachman is now known as Guest88217:02
opendevreviewRodolfo Alonso proposed openstack/nova master: Set "cache_ok=True" in "TypeDecorator" inheriting classes  https://review.opendev.org/c/openstack/nova/+/80735917:08
*** tbachman is now known as Guest88317:17
opendevreviewArtom Lifshitz proposed openstack/nova master: Gracefully power off guest on instance delete  https://review.opendev.org/c/openstack/nova/+/80847417:58
opendevreviewArtom Lifshitz proposed openstack/nova master: "Regression" test for server delete  https://review.opendev.org/c/openstack/nova/+/81095117:58
opendevreviewArtom Lifshitz proposed openstack/nova master: WIP: Make os_shutdown_timer a proper image property  https://review.opendev.org/c/openstack/nova/+/81095217:58
opendevreviewArtom Lifshitz proposed openstack/nova master: "Regression" test for server delete  https://review.opendev.org/c/openstack/nova/+/81095118:02
opendevreviewArtom Lifshitz proposed openstack/nova master: Gracefully power off guest on instance delete  https://review.opendev.org/c/openstack/nova/+/80847418:02
opendevreviewArtom Lifshitz proposed openstack/nova master: WIP: Make os_shutdown_timer a proper image property  https://review.opendev.org/c/openstack/nova/+/81095218:02
elodillesfungi: there is a patch that sets the lower-constraints job non-voting, but unfortunately it needed an impressive amount of rechecks and it is still not merged so far ( https://review.opendev.org/c/openstack/nova/+/809955 )18:57
elodillesalso there is another patch from gibi that pins the setuptools ( https://review.opendev.org/c/openstack/nova/+/810461 )18:59
funginote that the lower-constraints job was already not passing on stable/ussuri when setuptools updated19:04
elodilleshow do you mean?19:12
elodilleswhat I remember is that the gate was not blocked until the gate started to use setuptools 58.0.4.19:45
elodilleseven lower-constraints jobs were passing19:45
elodillesand the passing setuptools pinning patch also proves that there is no other issue (for now) than the one that was introduced by the latest setuptools release19:48
fungielodilles: oh, you're right, we got setuptools 58 in tox jobs when virtualenv 20.8.0 was released on 2021-09-16 at 12:52 utc and change 806628 was unlucky enough to be approved a few hours later at 16:23 utc that same day20:06
fungichange 810461 could probably instead do requires = virtualenv<20.8 if you wanted to be more flexible20:10

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