| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-05 | |||
| 09:54:54 | sean-k-mooney | bauzas: soft -1 i have two questions inline | |
| 09:55:07 | sean-k-mooney | over all the update looks good | |
| 10:17:09 | bauzas | sean-k-mooney: sorry I was afk as I need to taxi my daughter | |
| 10:18:02 | opendevreview | Merged openstack/nova stable/xena: Reproducer for bug 1951656 https://review.opendev.org/c/openstack/nova/+/866155 | |
| 12:22:29 | opendevreview | Sylvain Bauza proposed openstack/nova stable/xena: Handle mdev devices in libvirt 7.7+ https://review.opendev.org/c/openstack/nova/+/866156 | |
| 13:40:02 | dansmith | bauzas: gmann: can we enable functional-py311 in our tox? I submitted a patch yesterday I thought was passing functional, because when I ran it locally I got a passing tox run (of unit tests) | |
| 13:40:21 | dansmith | because of the silly tox behavior where it will run any missing testenv | |
| 14:14:09 | bauzas | dansmith: hem, yeah, I guess we can now support py 3.11 by the TC ? | |
| 14:14:36 | dansmith | I don't think we've made that call yet, no, but I don't see why we can't just have our tox not broken for people with 3.11-based dev machines | |
| 14:20:32 | dansmith | bauzas: ^ | |
| 14:21:33 | bauzas | dansmith: because you run tox -efunctional by default ? | |
| 14:22:05 | dansmith | bauzas: no, because if you run tox -efunctional-py311 right now, it will say "huh, there's no such testenv for that, so I'll just run the base one under that name and not say anything" ... which runs unit :) | |
| 14:22:07 | bauzas | sorry, I need to understand the problem | |
| 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 | |