| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-05 | |||
| 14:22:15 | dansmith | tox has always done | |
| 14:22:15 | bauzas | dansmith: hah, ok | |
| 14:22:16 | dansmith | that | |
| 14:22:22 | dansmith | tox -enot-a-real-thing will pass | |
| 14:22:48 | bauzas | dansmith: yeah because you pin the python version when calling the target | |
| 14:22:53 | dansmith | so I just want to put up a tox.ini modification to catch 311 as well | |
| 14:23:04 | dansmith | not really related to the python version | |
| 14:23:18 | dansmith | well, it is in the sense that functional-310 won't work | |
| 14:23:20 | bauzas | dansmith: okay, then you already had a patch ? | |
| 14:23:20 | dansmith | maybe that's what you mean | |
| 14:23:27 | dansmith | bauzas: locally, I'll push | |
| 14:24:43 | bauzas | dansmith: okay, then upload it | |
| 14:25:35 | opendevreview | Dan Smith proposed openstack/nova master: Allow running functional-py311 https://review.opendev.org/c/openstack/nova/+/879559 | |
| 14:28:33 | bauzas | dansmith: looks to me we don't need to wait for the TC to be saying we should support a python version, as we merged the same for 3.10 without this https://review.opendev.org/c/openstack/nova/+/839029 | |
| 14:28:51 | dansmith | right, like I said, I don't think that matters :) | |
| 14:28:54 | bauzas | dansmith: so, +1 to your change but you could add a non-voting job if you want | |
| 14:29:01 | dansmith | I was just asking because I was surprised nobody had done it | |
| 14:29:07 | dansmith | bauzas: I don't want a job | |
| 14:29:11 | dansmith | all I want is to be able to run it locally | |
| 14:29:33 | dansmith | without this, it will run unit tests instead of functional if you try | |
| 14:29:33 | bauzas | ack, if this is only for local testing, gtm | |
| 14:29:47 | dansmith | we can add a job when the TC moves us to a 3.11-based distro, this is just for local testing yes | |
| 14:30:35 | bauzas | all cool then | |
| 14:43:38 | opendevreview | Sylvain Bauza proposed openstack/nova master: Update to the PTL guide https://review.opendev.org/c/openstack/nova/+/875730 | |
| 15:28:38 | opendevreview | Dan Smith proposed openstack/nova master: Allow running functional-py311 https://review.opendev.org/c/openstack/nova/+/879559 | |
| 15:28:38 | opendevreview | Dan Smith proposed openstack/nova master: Add compute_id column to instances table https://review.opendev.org/c/openstack/nova/+/879499 | |
| 15:28:39 | opendevreview | Dan Smith proposed openstack/nova master: Add compute_id to Instance object https://review.opendev.org/c/openstack/nova/+/879500 | |
| 15:54:48 | opendevreview | Merged openstack/nova stable/xena: Handle mdev devices in libvirt 7.7+ https://review.opendev.org/c/openstack/nova/+/866156 | |
| 15:55:24 | opendevreview | Alexey Stupnikov proposed openstack/nova stable/victoria: Reattach mdevs to guest on resume https://review.opendev.org/c/openstack/nova/+/821980 | |
| 17:26:09 | gmann | dansmith: bauzas yes, that is what we did in past also to test the py version in advance so that we will make things compatible when it is in testing runtime | |
| 17:27:07 | gmann | dansmith: bauzas: do you know if any distro support it in their official release? we can add unit test job also as non voting in general template | |
| 17:27:23 | dansmith | fedora has it | |
| 17:27:32 | dansmith | I don't think we need to add a job yet, personally | |
| 17:27:56 | dansmith | I just don't want to run functional-py311, see it pass (because it's running unit tests), submit my patch and then see ALL the functionals have failed :P | |
| 17:28:05 | gmann | ok, I was waiting for debian to release it and we can add job that time | |
| 17:28:42 | gmann | true, adding functional tests run also on that is good idea | |
| 17:29:24 | dansmith | gmann: to be clear, I can run 'tox -epy311' and get unit tests on 3.11 as expected, | |
| 17:29:31 | dansmith | but I can't run functionals locally because there is no testenv | |
| 17:29:49 | dansmith | so tox just makes up a fake functional-py311 based on the base testenv (which is unit tests) and then lies to me :) | |
| 17:30:17 | gmann | dansmith: ah yeah due to default tox env https://review.opendev.org/c/openstack/nova/+/879559/2/tox.ini#3 | |
| 17:30:22 | dansmith | right | |
| 17:30:25 | gmann | dansmith: +W on your patch | |
| 17:30:28 | dansmith | thanks | |
| 17:37:29 | sean-k-mooney | i think 3.11 is also alredy in fedora 37 and will be in ubuntu 23.04 | |
| 17:37:41 | sean-k-mooney | so it should be in the cloud archve ocne that releases | |
| 17:38:30 | sean-k-mooney | 3.11.0~rc1 shoudl be in jammy-updates/universe packages already | |
| 17:38:54 | sean-k-mooney | so it wont be long before we have it on 22.04 | |
| 17:41:15 | sean-k-mooney | dansmith: oh while i think of it i appoved the schduler lazy loading patch thanks for the reminder | |
| 17:41:21 | dansmith | thanks | |
| 17:41:37 | sean-k-mooney | are we going to backport that | |
| 17:41:51 | sean-k-mooney | i assume so but not sure how far | |
| 17:41:59 | dansmith | upstream? I wouldn't think so | |
| 17:42:41 | sean-k-mooney | ok i would at least cherry pick it upstream to antelope if we are going to backpot it downstream and see what elodilles thinks | |
| 17:42:52 | sean-k-mooney | if nothign else it will give use a ci run and we can abandon it | |
| 17:43:08 | dansmith | there's a bug for it, but it doesn't really resolve an issue, it's more a serviceability feature :) | |
| 17:43:12 | dansmith | but yeah whatever | |
| 17:43:21 | dansmith | it can't go back any further than the conductor on | |
| 17:43:23 | dansmith | *one | |
| 17:43:34 | clarkb | dansmith: tox lying is one of the things I don't like about it. Nox is a lot more explicit | |
| 17:43:54 | dansmith | clarkb: I know, I've never understood that behavior | |
| 17:44:19 | sean-k-mooney | well its because we removed the config that froce it to use the specifed version since it "fixed" | |
| 17:44:32 | sean-k-mooney | dansmith: were you geting a non default python version locally | |
| 17:44:33 | clarkb | re python3.11 we're successfully using the rc package on jammy for unittests in zuul then rely on functional testing with python:3.11-bullseye based images to sanity check it | |
| 17:44:38 | sean-k-mooney | i.e. something other then 3.11? | |
| 17:45:10 | dansmith | no | |
| 17:45:27 | sean-k-mooney | clarkb: good to know but we should get teh full released version in like 2 or 3 weeks in 22.04 right? | |
| 17:45:28 | dansmith | sean-k-mooney: run this: 'tox -esnarglepuss9000' | |
| 17:46:03 | sean-k-mooney | ok that should create a default env sicne it wont match any of our default ones | |
| 17:46:10 | sean-k-mooney | and run whatever we have as the default | |
| 17:46:13 | dansmith | tox -e'failopotomus2000' | |
| 17:46:18 | dansmith | exactly | |
| 17:46:22 | dansmith | as does functional-py311 | |
| 17:46:38 | sean-k-mooney | yes that more or less what i expect | |
| 17:46:45 | sean-k-mooney | but if you did tox -e functional | |
| 17:46:49 | sean-k-mooney | it would have used 3.11 | |
| 17:46:55 | sean-k-mooney | if that is your system default | |
| 17:47:08 | sean-k-mooney | i know its not intuitive | |
| 17:47:28 | sean-k-mooney | but that was the behvior i observed when we looked at using the generitive envs | |
| 17:47:31 | dansmith | yeah, you understand that I understand, right? I just wanted it to be updated so I can use my aliases, which all specify the version | |
| 17:47:48 | sean-k-mooney | yep | |
| 17:47:56 | sean-k-mooney | no issue with the patch | |
| 17:48:07 | sean-k-mooney | i just avoid using the versioned ones ot not have that problem | |
| 17:48:35 | clarkb | sean-k-mooney: I don't know if they will update the full version in jammy | |
| 17:48:37 | clarkb | they might | |
| 17:49:16 | sean-k-mooney | the yave in the past (not the default) but ya not sure | |
| 17:50:04 | sean-k-mooney | i dont really mind using debian instead for the unit/functional tests if that is what makes sense | |
| 17:50:25 | sean-k-mooney | is 3.11 in the PTI runtimes this release | |
| 17:50:47 | sean-k-mooney | looks like no | |
| 17:51:24 | sean-k-mooney | https://github.com/openstack/governance/blob/master/reference/runtimes/2023.2.rst but it would still be nice to have some coverage | |
| 17:55:10 | clarkb | its also just faster ime. On tumbleweed locally it is 10% quicker on my machine to run zuul's unittests under python3.11 + x86_64-v3 than python3.10 without x86_64-v3 (can't be sure how much of that is python version vs cpu stuff though) | |
| 17:56:10 | sean-k-mooney | tumbleweed is compliing for x86_64-v3 | |
| 17:56:18 | sean-k-mooney | i think rhel 9 just moved to -v1 | |
| 17:57:20 | sean-k-mooney | oh actully v2 https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level | |
| 17:58:19 | sean-k-mooney | v3 gets avx2 which is nice but i woudl be surpised if that impacted unit tests | |
| 17:58:58 | sean-k-mooney | perhaps it impoved the hash funciton for dictonaries but either way 10% is nice | |
| 18:03:16 | clarkb | sean-k-mooney: they are doing overlay packages that do ldpreload magic or something | |
| 18:03:32 | clarkb | basically old cpu support remains then zypper detects if you've got a newer cpu and it will automaticall install the overlay packages too | |
| 18:03:53 | sean-k-mooney | ah ok so they are building for v3 and also for v2 or older | |
| 18:04:07 | sean-k-mooney | and using ldpreload to load the correct lib based on cpu support | |
| 18:04:36 | sean-k-mooney | ya i think rhel considerd that and tought it was too much work :) | |