Monday, 2022-05-23

Ugglao/07:35
opendevreviewElod Illes proposed openstack/nova stable/train: [stable-only] Use Tempest's run upper constraints from devstack  https://review.opendev.org/c/openstack/nova/+/84281307:35
gibigood morning07:53
*** elodilles is now known as elodilles_afk08:31
kashyapmelwitt: Thanks for that workaround for the 'query-migrate' call: https://review.opendev.org/c/openstack/nova/+/842687 :)08:31
opendevreviewBalazs Gibizer proposed openstack/nova master: Revert "Enable live_migration_events in nova-ovs-hybrid-plug"  https://review.opendev.org/c/openstack/nova/+/84293208:39
opendevreviewBalazs Gibizer proposed openstack/nova stable/xena: Reproducer unit test for bug 1934094  https://review.opendev.org/c/openstack/nova/+/84292209:10
opendevreviewBalazs Gibizer proposed openstack/nova stable/xena: Fix instance's image_ref lost on failed unshelving  https://review.opendev.org/c/openstack/nova/+/84292309:10
opendevreviewBalazs Gibizer proposed openstack/nova stable/wallaby: Reproducer unit test for bug 1934094  https://review.opendev.org/c/openstack/nova/+/84292509:11
opendevreviewBalazs Gibizer proposed openstack/nova stable/wallaby: Fix instance's image_ref lost on failed unshelving  https://review.opendev.org/c/openstack/nova/+/84292609:11
*** ministry is now known as __ministry09:48
opendevreviewBalazs Gibizer proposed openstack/nova stable/victoria: Reproducer unit test for bug 1934094  https://review.opendev.org/c/openstack/nova/+/84295209:49
opendevreviewBalazs Gibizer proposed openstack/nova stable/victoria: Fix instance's image_ref lost on failed unshelving  https://review.opendev.org/c/openstack/nova/+/84295309:49
opendevreviewBalazs Gibizer proposed openstack/nova stable/victoria: Reproducer unit test for bug 1934094  https://review.opendev.org/c/openstack/nova/+/84295209:58
opendevreviewBalazs Gibizer proposed openstack/nova stable/victoria: Fix instance's image_ref lost on failed unshelving  https://review.opendev.org/c/openstack/nova/+/84295309:58
opendevreviewBalazs Gibizer proposed openstack/nova stable/ussuri: Reproducer unit test for bug 1934094  https://review.opendev.org/c/openstack/nova/+/84295510:03
opendevreviewBalazs Gibizer proposed openstack/nova stable/ussuri: Fix instance's image_ref lost on failed unshelving  https://review.opendev.org/c/openstack/nova/+/84295610:03
opendevreviewMerged openstack/nova-specs master: Re-propose spec for ephemeral storage encryption  https://review.opendev.org/c/openstack/nova-specs/+/83587710:35
opendevreviewMerged openstack/nova-specs master: Re-propose spec for ephemeral encryption for libvirt  https://review.opendev.org/c/openstack/nova-specs/+/83607510:37
opendevreviewBalazs Gibizer proposed openstack/nova stable/train: Reproducer unit test for bug 1934094  https://review.opendev.org/c/openstack/nova/+/84296211:23
opendevreviewBalazs Gibizer proposed openstack/nova stable/train: Fix instance's image_ref lost on failed unshelving  https://review.opendev.org/c/openstack/nova/+/84296311:23
songwenpingbauzas: morning, have you used Tesla A100 card, how to use it binding to vm, is there any docs?11:43
sean-k-mooneysongwenping: i dont think we have them installed in our lab yet. we were goingt ot be adding some11:50
sean-k-mooneysongwenping: i think its more or less the same as the previous generation11:50
songwenpingsean-k-mooney: passthrough is same as the previous generation11:51
songwenpingbut vgpu usage is different.11:51
sean-k-mooneyvGPU can be too11:51
sean-k-mooneyit depense on if you enabel mig or not11:51
sean-k-mooneyform an openstack point of view even with mig enabled the nova config is baically the same11:51
sean-k-mooneywe still use mdevs for vGPU in mig mode11:52
songwenpingi have enabled mig, but i cannot find the vgpu types.11:52
sean-k-mooneybut the mdev is moved to the mig vf11:52
sean-k-mooneysongwenping: are you checking the PF or the VFs11:52
songwenpingi exec the sirov-manage, but it has no effect.11:53
sean-k-mooneyi have not used it but nvidia provide https://github.com/NVIDIA/mig-parted11:53
sean-k-mooneyto configre the a10011:53
sean-k-mooneythis would appear to be the set of supported profiles https://docs.nvidia.com/datacenter/tesla/mig-user-guide/index.html#a100-profiles11:55
sean-k-mooney"sudo nvidia-smi mig -lgip" shoudl list the profiles for you 11:56
songwenpingwe also need create mdev then attach to the guest?11:56
sean-k-mooneythe mdevs i think will still be created by nova11:57
sean-k-mooneybut you need to lookup the supproted mdev type in /sys11:57
sean-k-mooneyso with mig mode there are 2 steps11:58
songwenpingyeah, to generate uuid under devices dir by nova11:58
sean-k-mooneypartition the gpu wiht mig using the mig profiles11:58
sean-k-mooneythen lookup the mig vf pci adress and mdev type and update nova.conf with that11:58
songwenpingok, i'll try to check.11:59
sean-k-mooneythen nova will determin the numer of that mdev type that can be created and create an inventory of thaty type inplacement. when you schedule a vm we shoudl create the mdev automaticlly11:59
songwenpingright, thanks seak-k-mooney.12:00
songwenpingsorry, sean-k-mooney.12:01
sean-k-mooneyhehe given i have missspelled my own name in code comment no need to appologies for a typo :)12:02
sean-k-mooneyi was just lookign for our downstream bz for a100 but i cant find it readialy 12:02
sean-k-mooneyi think bauzas  wrote up how to do this at some point. they had a load of an 100 to test breifly but we dont have one dedicated for our use currently12:03
sean-k-mooneyah i found it but its private12:05
songwenpinglook forward to seeing soon.12:08
sean-k-mooneyit looks like they were using /usr/lib/nvidia/sriov-manage -e 0000:04:00.012:09
sean-k-mooneyto allocate teh VFs12:09
songwenpingi also use this command12:09
sean-k-mooneyand then if you used ll /sys/class/mdev_bus/*12:09
sean-k-mooneyyou woudl see the vfs12:09
sean-k-mooneyare mdev capable12:09
sean-k-mooneythey saw the same behvior with both t4(with updated firmware)  and a10012:10
songwenpingbut get nothing, maybe my env has something problem12:10
sean-k-mooneythen they create the mig instance "nvidia-smi mig -cgi 2g.10gb,2g.10gb,2g.10gb -C"12:10
sean-k-mooneyand the vf had inventories 12:10
sean-k-mooney cat /sys/class/mdev_bus/0000\:04\:01.0/mdev_supported_types/nvidia-475/available_instances 12:10
sean-k-mooneyso they added 12:11
sean-k-mooney[devices]12:11
sean-k-mooneyenabled_vgpu_types = nvidia-475,nvidia-112:11
sean-k-mooney[vgpu_nvidia-475]12:11
sean-k-mooneydevice_addresses = 0000:04:00.4,0000:04:00.5,0000:04:00.612:11
sean-k-mooney[vgpu_nvidia-1]12:11
sean-k-mooneydevice_addresses = 0000:00:00.112:11
sean-k-mooneyto the nova.conf12:11
sean-k-mooneysongwenping: the steps bauzas  did were12:12
sean-k-mooney nvidia-smi -i 0 -mig 112:12
songwenpingthanks sean-k-mooney12:12
sean-k-mooneyto enable mig12:12
sean-k-mooneywhich they checked with 12:12
sean-k-mooneynvidia-smi -i 0 --query-gpu=pci.bus_id,mig.mode.current --format=csv12:13
sean-k-mooneythen "/usr/lib/nvidia/sriov-manage -e 00:04:0000.0" to enable the vfs12:13
sean-k-mooneyand then you can use " ll /sys/class/mdev_bus/"12:13
sean-k-mooneyto verify that hte device are capable of hosting mdevs12:13
sean-k-mooneythen they configugred vgpu instance per mig instance12:14
sean-k-mooneynvidia-smi mig -cgi 2g.10gb,2g.10gb,2g.10gb -C12:14
sean-k-mooneyand after that they had 1 mdev inventory per vf12:14
sean-k-mooneywhich can be checked with "cat /sys/class/mdev_bus/0000\:04\:01.0/mdev_supported_types/nvidia-475/available_instances"12:15
sean-k-mooneysongwenping: hopefully that helps12:15
songwenpingthanks, this is useful.12:15
*** elodilles_afk is now known as elodilles12:16
sean-k-mooneyour downstream docs bz to write this up is still pending12:16
sean-k-mooneydansmith: those keystone select number really are an order of magnitude higher then everything else  https://paste.opendev.org/show/bsG9exlvGqaNZrbhEnJp/12:34
gibimelwitt: can I help somehow to convince you to +2 https://review.opendev.org/c/openstack/nova-specs/+/791047 ? :) 12:59
sean-k-mooneygibi: she may have been leaving that to stephenfin to +2w but if melwitt is happy withthe proposal i think stephenfin will be happy that you have incoperated there feedback with regards to the dynmaic alloctaiton fo VF/PFs13:03
gibiahh OK.13:05
gibistephenfin: if you have time, I think https://review.opendev.org/c/openstack/nova-specs/+/791047 is ready for a +2+A :)13:05
* sean-k-mooney agrees for what its worth but may need to ensure they are sitting down if that actully merges13:06
gibiI'm not sure I understand what the sitting down part means ^^13:08
sean-k-mooneypreparing my self for the shock of us agreeing to actully track pci device in placement after like what 5 years13:09
gibiahh :d13:09
gibi:D13:09
sean-k-mooneyplacement was still in nova wehn we started this converastion and nested resouce providers did not exist13:09
gibiyeah it is a long journey 13:10
gibiand it is not over yet :)13:10
opendevreviewribaudr proposed openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances  https://review.opendev.org/c/openstack/nova-specs/+/83366913:32
dansmithsean-k-mooney: I know.. something has to be wrong right?13:49
sean-k-mooneypresumable. i would expect keysone to be higher then the rest but not 10x13:50
sean-k-mooneyand that 10x neutron which is also higher then the rest13:51
dansmithright13:51
dansmithneutron goes over keystone quickly during tempest tho13:52
sean-k-mooneydansmith: while your here we use 2 allocation for live migration correct? one is held by the instnace an the other by the migration uuid?14:11
dansmithyeah14:11
sean-k-mooneydo you remember when that change was made it was 5 or more cycles ago right14:11
sean-k-mooneyas in its not recent14:11
sean-k-mooneyhttps://bugs.launchpad.net/nova/+bug/1975490 just in the context of that14:11
dansmithoh jeez, no idea, but I'm sure it was 5+ ago14:11
sean-k-mooneyright it was well before train with the new vcpu code 14:12
sean-k-mooneythey did not say what version of openstack they were using but im guessign it was quite an old version if they are seeing placment check the source allocations like they describe14:13
sean-k-mooneyi dont think any supported branch including the ones in EM still use a signel allocation for both hosts14:14
dansmithyeah I'm sure not14:15
sean-k-mooneywe will see if they respond i guess14:15
opendevreviewribaudr proposed openstack/nova-specs master: Allow unshelve to a specific host  https://review.opendev.org/c/openstack/nova-specs/+/83150614:30
*** mfo is now known as Guest6714:47
*** mfo_ is now known as mfo14:47
kashyapmelwitt: When you're about, can you review this, please: https://review.opendev.org/c/openstack/nova/+/838926 (It already has a +2 from gibi)15:14
kashyap(And it is successfully tested by a Red Hat contributor downstream)15:15
kashyapbauzas: --^15:18
*** beekneemech is now known as bnemec15:39
melwittbauzas, elodilles, gmann: I started an etherpad for stable branch ci here. will fill it in with more info https://etherpad.opendev.org/p/nova-stable-branch-ci15:42
melwittkashyap: thanks for noticing :)15:43
melwittgibi, sean-k-mooney: yeah I thought stephenfin may want to look  at the current spec bc he had a lot of feedback in previous PS15:44
stephenfinoh, I'm looking at it at the moment15:44
kashyapmelwitt: I recall debugging it with you in the past; thanks for bringing it to its logical conclusion15:44
kashyapLooks good to me to workaround it.  (Also, the CI failure seems unrelated)15:45
melwittstephenfin: great :)15:45
melwittkashyap: will also review your patch15:46
kashyapmelwitt: It's also a workaround :D15:46
melwitthaha nice15:46
elodillesmelwitt: thanks \o/ it was on my TODO as well o:)15:46
kashyapmelwitt: But it is functionally tested by a Red Hat support eng downstream15:47
kashyap(And it works)15:48
gmannmelwitt: ack, thanks. 15:48
melwittkashyap: ack15:48
kashyapThank you15:49
elodillesmelwitt: i proposed quite many bandit capping patches in the past, but did not notice that placement needs it :-o ( https://review.opendev.org/q/topic:cap-bandit-1.6.2 )15:54
melwittelodilles: yeah I remembered that being a thing and I think I found your patches for other projects. placement had been working ok for awhile, not actually sure when this cropped up. backports don't get proposed there often15:56
bauzasUggla: made a review with a French link on https://review.opendev.org/c/openstack/nova-specs/+/831506/15:58
* bauzas did this for the first time in 9 years :)15:58
bauzaseither way, +2d15:58
bauzascores, a spec seems very close to be accepted https://review.opendev.org/c/openstack/nova-specs/+/831506/4.5515:58
bauzascores, a spec seems very close to be accepted https://review.opendev.org/c/openstack/nova-specs/+/831506/4..5 even15:58
* bauzas feels brave to review https://review.opendev.org/c/openstack/nova-specs/+/791047 now as he promised too much on it15:59
elodillesmelwitt: yeah, and we have periodic-stable-jobs in placement only since xena: https://review.opendev.org/c/openstack/placement/+/77538416:00
stephenfingibi: sean-k-mooney: melwitt: My only comment is on the config option. 'device_list' suggests it's a list but it's not - it's a MultiStrOpt (meaning you'd simply specify it multiple times in nova.conf)16:01
melwittelodilles: ah right16:02
elodillesmelwitt: we have the periodic-weekly for master, but maybe this worth a backport if we want to catch broken gates on older stable branches 16:02
gmannbauzas: FYI, i will be absent in nova meeting tomorrow as we have 'release naming meeting' at the same time - http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028618.html16:02
stephenfinWe can bikeshed on the correct name for that now or later, I don't mind. So long as we don't call it a plural thing when it's not actually plural16:02
gibistephenfin: hm16:04
sean-k-mooneystephenfin: well eventully we shoudl make it a list instad of a multi opt16:04
sean-k-mooneystephenfin: the alisa support json list syntax or mutlti opt repating16:04
sean-k-mooneystephenfin: generally it enables multipel things by the way16:05
sean-k-mooneyit supprots regex and glob mathch or you can just use vender id and product id16:05
gibistephenfin: we can drop the _list postfix and simply call it [pci]devices16:05
sean-k-mooneyya that would work16:06
sean-k-mooneygibi: stephenfin  if ye want to s/device_list/devices/ im fine with that16:12
sean-k-mooneyand or do it as a followup16:12
gibias I see stephenfin has things against the pluralness as well16:12
gibianyhow I will reply in the spec and we can discuss it tomorrow over IRC16:13
sean-k-mooneywell from my point of view it is plural as it generally refers to multiple devices via the vendor/product id or the regex support16:13
sean-k-mooneysure16:13
sean-k-mooneyelodilles: by the way i propsoed https://review.opendev.org/c/openstack/requirements/+/842991 to test if that will help with stable/ussuri16:14
sean-k-mooneyelodilles: i think that woudl pull in most of the wait for sshabel changes but certenly not all16:14
sean-k-mooneythere are some other idea we had of how to impove the stabel branch situation but that was the lowest effort quick change we cam up with16:15
sean-k-mooneyah actully i might need older16:16
sean-k-mooneywe might be hitting py36 issues witht hat16:16
sean-k-mooneyalthough we should supprot 36 on yoga so proably somethign else16:17
sean-k-mooneyah oslo_log dependices16:18
sean-k-mooneyhum why is that using upper constratis form master16:19
sean-k-mooneyhttps://zuul.opendev.org/t/openstack/build/1f08c1134a1540bb8e9ae836c5ba60a9/log/job-output.txt#20845 ERROR: Could not find a version that satisfies the requirement oslo.log===5.0.0 (from -c https://releases.openstack.org/constraints/upper/master16:19
bauzasgmann: ack no worries16:20
sean-k-mooneyok i need to also change devstack to work aroudn that16:21
gibidansmith: could you check the unshelve to host spec https://review.opendev.org/c/openstack/nova-specs/+/831506/ I think now it is also aligned to you comments too16:26
dansmithoh yeah I saw this ack16:27
dansmithoops16:27
dansmiththat was intended to be two statements to two different people, but it worked out this time :)16:27
* dansmith 's irc client has one input buffer, which persists when switching tabs :/16:27
sean-k-mooneyoh i have debated if that was useful in the past16:28
sean-k-mooneyi sometimes start replyint in the wrong tab if  misclick16:28
sean-k-mooneybut more often then not i assuem that causes issues16:28
gibi:)16:29
dansmithI'm not a fan.. end up with too many "that guy is an ass okay sure buddy" things where you don't remember to hit send in a /query and then switch16:29
sean-k-mooneyhttps://review.opendev.org/c/openstack/requirements/+/842991 is going to fail but even using an old upper-constriats i think wont work16:33
sean-k-mooneyits been resolving for ~5 mins locally 16:33
sean-k-mooneyrealistically if i want to bump the tempest version i think i would need to either do this differently via devstack or bump other constraits 16:34
sean-k-mooneyactully the best apptoch might be to just not use an upper-constratits file for the venv16:41
dansmithgibi: I have one typo gripe plus bauzas16:44
dansmithcan we fix and re-ack real quick?16:44
dansmithI can edit inline and then +2 if you'll be around to +W16:44
bauzasdansmith: sure16:44
opendevreviewDan Smith proposed openstack/nova-specs master: Allow unshelve to a specific host  https://review.opendev.org/c/openstack/nova-specs/+/83150616:45
bauzasgibi: I'll have comments on the PCI spec, mostly on the config options 16:45
sean-k-mooneyok i think the best way to make this work is just to remove using upper-constraits from the venv in devstack ill try that and see if that work 16:45
dansmithbauzas: gibi done16:45
bauzasdansmith: saw16:45
bauzasUggla: typey typey now16:46
Uggla?16:46
bauzasUggla: your spec got approved16:53
bauzaswhich means "hands on deck now"16:53
Ugglaoh cool16:53
gibidansmith, bauzas: thanks16:59
sean-k-mooneygmann: o/ hi looks like you are also tryinng to use a newer version of tempest on ussuri17:04
sean-k-mooneyhttps://review.opendev.org/c/openstack/devstack/+/83805117:04
sean-k-mooneyim trying to do the same with https://review.opendev.org/c/openstack/requirements/+/842991 andhttps://review.opendev.org/c/openstack/devstack/+/84300617:04
sean-k-mooneyok im going to call it a day but ill take a look at those again tomorrow17:07
opendevreviewMerged openstack/nova-specs master: Allow unshelve to a specific host  https://review.opendev.org/c/openstack/nova-specs/+/83150617:14
melwittsean-k-mooney: have you seen this re: upper-constraints? https://review.opendev.org/c/openstack/nova/+/84281317:16
melwittoh, nvm, I guess that's what you just talking about the last few messages17:16
sean-k-mooneyno i had not17:18
sean-k-mooneybut i dont think we want to do that17:18
sean-k-mooneyi dont really agree with pinnint tempest but if we do im not conviced we shoudl do it via devstack17:18
sean-k-mooneywe could but i think we need to contol that form the project side unless the QA team want to support all the brances we care about including the EM ones17:19
melwittit's a nova patch17:20
sean-k-mooneyi know but devstack does nto seam to use the right version17:20
sean-k-mooneyeither17:20
sean-k-mooneyat least on the stable branch of the requirement repo it uses master17:20
sean-k-mooneynot the patch under test17:21
sean-k-mooneyit looks like on stable its using the checked out version of the requiremetns repo17:22
sean-k-mooneywell on train https://github.com/openstack/devstack/blob/stable/train/stackrc#L32017:22
sean-k-mooneythat would be fine i guess if tha tis the correct branch17:22
sean-k-mooneymelwitt: https://github.com/openstack/devstack/blob/stable/ussuri/stackrc#L315=17:23
sean-k-mooneyon ussui it woudl end up using master17:23
sean-k-mooneymelwitt: so i guess that patch is fine for train17:23
sean-k-mooneybut not for ussuri17:23
melwitthm ok17:24
sean-k-mooneylook like gmann pinned train with https://github.com/openstack/devstack/commit/8a22f7380c7029e931fe9103320f24a223b619d117:25
sean-k-mooneyso i guess the train patch is fine to merge17:26
sean-k-mooneybut that would not help with ussuri17:26
gibibauzas: thanks for the review, replied in https://review.opendev.org/c/openstack/nova-specs/+/79104717:26
sean-k-mooneymelwitt: i kind of would have epected the newer stable branches to be fix before train17:26
sean-k-mooneybut maybe its because train is EM already17:27
opendevreviewribaudr proposed openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances  https://review.opendev.org/c/openstack/nova-specs/+/83366917:27
sean-k-mooneymelwitt: mind if we pick this up tomorrow the train nova patch is likely ok to proceed with17:27
melwittsean-k-mooney: it might be an oversight? gmann ^17:27
melwittsean-k-mooney: sure17:27
sean-k-mooneyi would think using the locally checked out requiremetn repo would always be valid17:28
sean-k-mooneyand that instead of a stable only change we coudl have done this on master and backported17:28
sean-k-mooneyat least on the nova side17:28
sean-k-mooneyanyway got to run and pick up food for dinner17:29
melwittyeah, that does make sense17:29
melwitto/17:30
elodillesmelwitt: about the TEMPEST_VENV thing: afaik that is intentional: tempest should run always against master in 'maintained' stable branches (that's why it is in venv)17:59
melwittelodilles: I replied on the review, I see what you mean, it was my misunderstanding. I see now that tempest is pinned on train but not elsewhere18:00
melwittthanks for the quick reply :)18:00
elodillesmelwitt: oh, sorry :) haven't seen your answer yet o:)18:01
melwittno worry, I posted it only a minute ago :)18:01
elodilles:)18:02
melwittI should have said "I also replied on the review"18:02
elodillesno problem :) i really wonder how these new problems crept into ussuri and train... i mean, the SSHABLE thing was not needed before, so why now? did we merge something to nova? or did it come with some other dependencies? :/18:08
melwittelodilles: same. looking at a CI run from today on stable/ussuri, one thing it's failing on the same oslo.log dep issue as on stable/train https://zuul.opendev.org/t/openstack/build/571459b47ccb4ed1854f61ce99597eca18:12
melwittERROR:   full: could not install deps [-chttps://releases.openstack.org/constraints/upper/master, -r/opt/stack/tempest/requirements.txt]; v = InvocationError('/opt/stack/tempest/.tox/tempest/bin/pip install -chttps://releases.openstack.org/constraints/upper/master -r/opt/stack/tempest/requirements.txt', 1)18:14
elodillesmelwitt: oslo.log 5.0.0 dropped py36 & py3718:29
elodillesso yes it seems it is used from master's upper-constraints.txt :S18:30
elodillesbut on ussuri we have zuulv3. so you are right, we need a fix for ussuri then, too :S (though it will be probably a different fix, because the hook does not exist there anymore)18:33
melwittyeah :/18:35
melwittsean-k-mooney has been looking at it18:35
elodillesi guess from zed till victoria now things are running with py38 and now that during zed some project dropped py36 support we need to pin things where still py36 is used only18:46
elodillesi.e. on ussuri and train18:46
sean-k-mooneyelodilles: the sshable thing is needed partly because of a qemu change and partly because it was always a race20:24
sean-k-mooneyelodilles: it was previoulsy undefined behaivor to retry detach20:24
sean-k-mooneywe have always had races in those tests too with the kernel attachiting the device so it was technially always need but it was not an issue in the past20:25
sean-k-mooneyi dont know if canonical have backproted the change or centos have in the stable brances to qemu20:25
sean-k-mooneybut it could jsut be that the ci is runing slightly slower and now we are lossing rahter then wining the race20:26
sean-k-mooneyelodilles: using master requirement with master tempest makes sesnse but on any branch where we pin tempest we have to also pinn the upper constraits20:27
sean-k-mooneywe also need to deal with py36 by either using py38 to run tempest20:27
sean-k-mooneyon stable ussuri or using older requirements to work around oslo droping support20:28
sean-k-mooneybasiclaly not that master does not use py36 we cant use master in any job the uses py36 for the upper constraits so we need to cap to yoga at the latest20:30
opendevreviewMerged openstack/nova stable/train: [stable-only] Use Tempest's run upper constraints from devstack  https://review.opendev.org/c/openstack/nova/+/84281321:17
gmannsean-k-mooney: I did not get about your 'unpined' things. For all EM, we pin Tempest in devstack and so does compatible  upper constraints to use. for ussuri, I am trying with tempest 30 but I have not finished that yet.23:43
gmannsean-k-mooney: note, project can always override the pin tempest version and constraints via devstack variable in job so projects side choice still available 23:43
gmannI am not clear what exactly we miss to pin the Tempest for EM branch. All good there right? 23:45
melwittgmann: I put the ussuri issue on the etherpad https://etherpad.opendev.org/p/nova-stable-branch-ci basically it's failing the same way train was, failing to install oslo.log version coming from upper-constraints master23:50
gmannmelwitt: thanks. I started working on this but then forget to figure out the failure and release - https://review.opendev.org/q/topic:ussuri-last23:54
gmannI will work on that23:54
melwittah k cool23:58
gmanndue to some constraint mismatch in Tempest master and stable/ussuri, it is little complicated and I am trying to see what combination of Tempest and constraint will work23:59

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