| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-23 | |||
| 17:27:15 | opendevreview | ribaudr proposed openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/833669 | |
| 17:27:31 | sean-k-mooney | melwitt: mind if we pick this up tomorrow the train nova patch is likely ok to proceed with | |
| 17:27:36 | melwitt | sean-k-mooney: it might be an oversight? gmann ^ | |
| 17:27:47 | melwitt | sean-k-mooney: sure | |
| 17:28:18 | sean-k-mooney | i would think using the locally checked out requiremetn repo would always be valid | |
| 17:28:31 | sean-k-mooney | and that instead of a stable only change we coudl have done this on master and backported | |
| 17:28:48 | sean-k-mooney | at least on the nova side | |
| 17:29:24 | melwitt | yeah, that does make sense | |
| 17:29:24 | sean-k-mooney | anyway got to run and pick up food for dinner | |
| 17:30:01 | melwitt | o/ | |
| 17:59:36 | elodilles | melwitt: 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) | |
| 18:00:23 | melwitt | elodilles: 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 elsewhere | |
| 18:00:40 | melwitt | thanks for the quick reply :) | |
| 18:01:21 | elodilles | melwitt: oh, sorry :) haven't seen your answer yet o:) | |
| 18:01:36 | melwitt | no worry, I posted it only a minute ago :) | |
| 18:02:08 | elodilles | :) | |
| 18:02:25 | melwitt | I should have said "I also replied on the review" | |
| 18:08:12 | elodilles | no 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:12:38 | melwitt | elodilles: 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/571459b47ccb4ed1854f61ce99597eca | |
| 18:14:20 | melwitt | ERROR: 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:29:41 | elodilles | melwitt: oslo.log 5.0.0 dropped py36 & py37 | |
| 18:30:31 | elodilles | so yes it seems it is used from master's upper-constraints.txt :S | |
| 18:33:05 | elodilles | but 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:35:23 | melwitt | yeah :/ | |
| 18:35:25 | melwitt | sean-k-mooney has been looking at it | |
| 18:46:20 | elodilles | i 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 only | |
| 18:46:45 | elodilles | i.e. on ussuri and train | |
| 20:24:12 | sean-k-mooney | elodilles: the sshable thing is needed partly because of a qemu change and partly because it was always a race | |
| 20:24:37 | sean-k-mooney | elodilles: it was previoulsy undefined behaivor to retry detach | |
| 20:25:15 | sean-k-mooney | we 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 past | |
| 20:25:44 | sean-k-mooney | i dont know if canonical have backproted the change or centos have in the stable brances to qemu | |
| 20:26:20 | sean-k-mooney | but it could jsut be that the ci is runing slightly slower and now we are lossing rahter then wining the race | |
| 20:27:06 | sean-k-mooney | elodilles: using master requirement with master tempest makes sesnse but on any branch where we pin tempest we have to also pinn the upper constraits | |
| 20:27:53 | sean-k-mooney | we also need to deal with py36 by either using py38 to run tempest | |
| 20:28:22 | sean-k-mooney | on stable ussuri or using older requirements to work around oslo droping support | |
| 20:30:13 | sean-k-mooney | basiclaly 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 latest | |
| 21:17:04 | opendevreview | Merged openstack/nova stable/train: [stable-only] Use Tempest's run upper constraints from devstack https://review.opendev.org/c/openstack/nova/+/842813 | |
| 23:43:03 | gmann | sean-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:46 | gmann | sean-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:45:08 | gmann | I am not clear what exactly we miss to pin the Tempest for EM branch. All good there right? | |
| 23:50:24 | melwitt | gmann: 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 master | |
| 23:54:45 | gmann | melwitt: thanks. I started working on this but then forget to figure out the failure and release - https://review.opendev.org/q/topic:ussuri-last | |
| 23:54:50 | gmann | I will work on that | |
| 23:58:17 | melwitt | ah k cool | |
| 23:59:01 | gmann | due 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 work | |
| #openstack-nova - 2022-05-24 | |||
| 01:53:35 | opendevreview | Ghanshyam proposed openstack/nova stable/ussuri: DNM: Testing stable/ussuri with tempest fix for constraints mismatch https://review.opendev.org/c/openstack/nova/+/843046 | |
| 07:07:21 | sean-k-mooney[m] | gmann is ussuri EM or supported currently | |
| 07:07:35 | sean-k-mooney[m] | because it seams to be useing master uc | |
| 07:07:48 | sean-k-mooney[m] | but has pinned tempest | |
| 07:08:28 | sean-k-mooney[m] | so i think we either need to have it use python 3.8 so that master uc works | |
| 07:08:59 | sean-k-mooney[m] | or we need to chanve uc to be <= instead of === | |
| 07:11:05 | sean-k-mooney[m] | gmann: if we dont pin i think we canc get it to install but i was actully using 3.9 to test i was going to try deplying ussuri today | |
| 07:11:32 | sean-k-mooney[m] | i was using one of my centos 9 vms to test yesterday which was too new to test properly | |
| 07:18:03 | opendevreview | Rico Lin proposed openstack/nova-specs master: Add vIOMMU device support for libvirt driver https://review.opendev.org/c/openstack/nova-specs/+/840310 | |
| 07:19:44 | ricolin | stephenfin: I need your feedback on comment https://review.opendev.org/c/openstack/nova-specs/+/840310/7..10/specs/zed/approved/libvirt-viommu-device.rst#b52 thanks :) | |
| 07:20:53 | ricolin | Also for aw_bits, I propose we set it to 48 (which at least will cover both 39 and 48 width option ) and don't expose it to end user | |
| 07:38:24 | sean-k-mooney[m] | ricolin if 48 is supported on our min version of qemu im ok to hard code to that | |
| 07:38:56 | sean-k-mooney[m] | at least for now until we have a need for something higher | |
| 07:55:26 | whoami-rajat | hi #openstack-nova , wanted to add a topic to today's meeting agenda, do we have an etherpad for the meeting? | |
| 07:55:48 | sean-k-mooney[m] | we have a wiki page | |
| 07:56:10 | whoami-rajat | ack, can i add topics there? | |
| 07:56:49 | sean-k-mooney[m] | yep just add it to the adgenda here https://wiki.openstack.org/wiki/Meetings/Nova https://wiki.openstack.org/wiki/Meetings/Nova | |
| 08:04:49 | whoami-rajat | done, thanks! | |
| 10:31:22 | opendevreview | Rajesh Tailor proposed openstack/nova master: Fix typos https://review.opendev.org/c/openstack/nova/+/843127 | |
| 11:08:58 | ricolin | sean-k-mooney[m]: aw_bit is introduced since libvirt 6.5.0 is that means I should propose in spec to bump min version for libvirt/qemu as well? | |
| 11:09:21 | ricolin | current: MIN_LIBVIRT_VERSION = (6, 0, 0) | |
| 11:09:24 | sean-k-mooney | libvirt 6.5.0 or qemu | |
| 11:09:42 | sean-k-mooney | ricolin: we have to advertise or min version bumps in advance | |
| 11:09:50 | sean-k-mooney | so in general no | |
| 11:10:08 | sean-k-mooney | but i need to check when we last did that | |
| 11:10:19 | ricolin | thanks | |
| 11:12:14 | sean-k-mooney | looking at https://docs.openstack.org/nova/latest/reference/libvirt-distro-support-matrix.html i dont think we can increase it this cycle | |
| 11:12:23 | sean-k-mooney | we shoudl be able to do it in AA | |
| 11:12:54 | sean-k-mooney | we need to still suport 20.04 this cycle | |
| 11:13:13 | sean-k-mooney | but we can go to libvirt 7.0 in AA | |
| 11:13:26 | sean-k-mooney | and qemu 5.2 | |
| 11:14:05 | sean-k-mooney | ricolin: so yes you will need to do a min version check and either not set the value or reject the boot | |
| 11:21:49 | ricolin | sean-k-mooney: So this patch might gonna need to wait AA to bump libvirt 7.0.0 if we keep aw_bits 48(which required min libvirt version 6.5.0), right? | |
| 11:22:49 | sean-k-mooney | ricolin: no it can proceed | |
| 11:23:03 | sean-k-mooney | but you can only set the aw_bit if the hsot has 6.5.0 | |
| 11:23:25 | ricolin | ah, got it | |
| 11:23:31 | sean-k-mooney | so on older version the address with woudl not be defined which would limit the device that could be used | |
| 11:24:15 | sean-k-mooney | but if you are not using pci passthough it might still be fine or if you are but dont need the extended adresspace width | |
| 12:24:08 | opendevreview | Merged openstack/nova stable/wallaby: Define new functional test tox env for placement gate to run https://review.opendev.org/c/openstack/nova/+/840717 | |
| 13:26:36 | kashyap | sean-k-mooney: On my fresh F36 I see these pip conflicts - do you see too? - https://paste.opendev.org/show/baAm2JxuzDLCsviaK90D/ | |
| 13:33:58 | sean-k-mooney | what version of python are you using | |
| 13:34:07 | sean-k-mooney | ill check but i dont think so | |
| 13:34:14 | sean-k-mooney | that was nova right | |
| 13:34:19 | kashyap | Yeah | |
| 13:34:32 | kashyap | python3-3.10.4-1.fc36.x86_64 | |
| 13:35:05 | sean-k-mooney | we dont fuly supprot 3.10 yet | |
| 13:35:18 | sean-k-mooney | its experimental and will be added next cycle | |
| 13:35:33 | sean-k-mooney | we test with up to 3.9 as voting so there may be issue if you use 3.10 | |
| 13:35:51 | sean-k-mooney | i have 3.10 locally i think so ill try 3.9 and 3.10 | |
| 13:37:08 | gibi | kashyap: I haven't seen that yet but it does not seem to be a py310 specific issue. I can try it in a clean env | |
| 13:38:08 | sean-k-mooney | kashyap: wa that just unit test by the way | |
| 13:38:15 | sean-k-mooney | i.e. tox -e py3 | |
| 13:38:25 | kashyap | sean-k-mooney: Yeah, I was just trying to run a unit test | |
| 13:39:34 | kashyap | sean-k-mooney: Yes, it was a `tox -e py36[|37] some_test` | |
| 13:39:55 | gibi | on master? | |