bauzas | good morning Nova | 07:45 |
---|---|---|
pslestang | Hey all, I'm facing an issue on a fresh installed devstack when running tox in nova directory which seems related to a conflict between oslo-vmware and suds-jurko | 07:57 |
pslestang | ERROR: Cannot install -r /opt/stack/nova/test-requirements.txt (line 28) because these package versions have conflicting dependencies. | 07:57 |
pslestang | The conflict is caused by: | 07:57 |
pslestang | oslo-vmware 3.9.1 depends on suds-jurko>=0.6 | 07:57 |
pslestang | The user requested (constraint) suds-jurko===0.6 | 07:57 |
pslestang | Is there a recommended fix or a solution to handle that? | 07:58 |
bauzas | pslestang: weirdo | 07:58 |
bauzas | which tox target ? | 07:58 |
bauzas | I usually don't run my unittest on devstack but rather on my local machine | 07:59 |
bauzas | at least because sometimes my whole local nova repo can disappear if I clean up devstack :) | 08:00 |
bauzas | I rather prefer to have a local working repo and a git remote on my devstack | 08:00 |
pslestang | I did not specify any target | 08:00 |
bauzas | so, just 'tox' ? | 08:01 |
pslestang | yep | 08:01 |
bauzas | ok, so unittests | 08:01 |
bauzas | you should tox -r | 08:01 |
bauzas | which will recreate the tox venv | 08:01 |
pslestang | ok trying | 08:01 |
bauzas | and you should also specify a target :) | 08:02 |
bauzas | -e py38 per say :) | 08:02 |
bauzas | also, running the whole testsuite is nice but... needs a lot of coffee to get answers :) | 08:03 |
bauzas | you should rather point tox to check only a few tests you know | 08:03 |
pslestang | running 'tox -r' it does not change anything | 08:03 |
bauzas | pslestang: paste the outputs please | 08:04 |
bauzas | so I can try to reproduce the exact command | 08:04 |
bauzas | mmm, maybe we have a regression in our CI, checking zuul | 08:06 |
bauzas | actually, no, all looks good https://zuul.openstack.org/builds?project=openstack/nova | 08:07 |
pslestang | which paste tool are you using, paste.openstack.org tells me that I send spam | 08:09 |
pslestang | bauzas: https://privatebin.net/?18300286850a2784#BxNwm4jkzNKC4gYbPiTS11uXJvLUuq6UVHxRAv7yYXyK | 08:13 |
bauzas | pslestang: you can force paste.o.o to accept your paste AFAICR | 08:14 |
bauzas | hah | 08:14 |
bauzas | error in suds-jurko setup command: use_2to3 is invalid. | 08:14 |
bauzas | that rings a bell to me :) | 08:15 |
bauzas | testing locally | 08:18 |
pslestang | ok thank you | 08:18 |
bauzas | pslestang: one quick thought could be that your nova local repo is a bit old and not getting the latest releases | 08:19 |
bauzas | pslestang: yeah, confirmed, I can run tox locally on py38 target without any problem | 08:19 |
pslestang | The repo is fresh from this morining | 08:20 |
bauzas | ? | 08:20 |
bauzas | I just did a git pull before I recreated the venv :) | 08:20 |
bauzas | pslestang: last commit on your nova git repo ? | 08:21 |
bauzas | mine is : | 08:21 |
pslestang | fdfdba265833d237e22676f9a223ab8ca0fe1e03 | 08:21 |
bauzas | commit fdfdba265833d237e22676f9a223ab8ca0fe1e03 (HEAD -> master, origin/master, origin/HEAD) | 08:21 |
bauzas | Merge: a8d3ab2513 ad227d7085 | 08:21 |
bauzas | Author: Zuul <zuul@review.opendev.org> | 08:21 |
bauzas | Date: Fri Oct 8 02:36:41 2021 +0000 | 08:21 |
bauzas | Merge "Update min supported service version for Yoga" | 08:21 |
pslestang | same here | 08:21 |
bauzas | pslestang: can you try to run tox on a local repo which is *not* devstack ? | 08:22 |
bauzas | git clone nova and shoot the tox runs | 08:22 |
pslestang | let me give a try | 08:22 |
bauzas | I'd suspect some pip cache | 08:22 |
pslestang | same result, I'm gonna try by cleaning pip cache it sounds like a good point | 08:25 |
frickler | pslestang: bauzas: https://bugs.launchpad.net/devstack/+bug/1946340 . we should mark that as FAQ somewhere | 08:44 |
frickler | the issue isn't seen in our CI because we use pre-built wheels | 08:44 |
frickler | if you do a local build without old pip cache, it will fail the same way | 08:45 |
pslestang | frickler: you're completely right | 08:46 |
bauzas | pslestang: yeah, eventually spotted the depency issue with devstack by reinstalling my testbed | 08:47 |
bauzas | dependency* even | 08:47 |
pslestang | I will try by pining the setuptools to 58.0.0 as proposed https://bugs.launchpad.net/devstack/+bug/1946340/comments/5 | 08:51 |
*** bauzas_ is now known as bauzas | 08:57 | |
bauzas | ergh, network glitch here | 08:57 |
bauzas | frickler: fwiw, cinder installation on devstack failed due to this | 09:06 |
bauzas | I can't see any proper workaround | 09:07 |
sean-k-mooney[m] | for now you just remove oslo.vmware from cinders requirements file | 09:07 |
bauzas | frickler: pslestang: about documenting it, we already discussed about the 2_to_3 issues we got and the pinned setuptools and we said "well, this isn't a nova issue, so why should we create some relnotes for this ?" | 09:07 |
sean-k-mooney[m] | ill try and submit a fix to oslo.vmware to use suds-community shortly | 09:07 |
bauzas | sean-k-mooney: locally, you mean ? ok | 09:08 |
sean-k-mooney[m] | this is not a devstack bug | 09:08 |
sean-k-mooney[m] | yes locally | 09:08 |
sean-k-mooney[m] | i just commented it out | 09:08 |
sean-k-mooney[m] | but the issue is in oslo.vmware it depens on suds-jaroko or something like that | 09:09 |
sean-k-mooney[m] | suds-community is python 3 compatible | 09:09 |
sean-k-mooney[m] | so once we fix there requirements file you can skip the local workaround | 09:09 |
bauzas | yes | 09:09 |
frickler | bauzas: yes, local workaround is to remove oslo.vmware from cinder requirements | 09:15 |
bauzas | kk | 09:15 |
frickler | sean-k-mooney[m]: there is already one, it needs to be added to reqs first, though: https://review.opendev.org/c/openstack/oslo.vmware/+/813377 | 09:16 |
frickler | sean-k-mooney[m]: also, the most recent version of suds-community still hasn't fixed the 2to3 issue. but they provide wheels on pypi, which masks that issue | 09:17 |
sean-k-mooney[m] | ah ok good | 09:17 |
frickler | they need a new tag with this one https://github.com/suds-community/suds/pull/58 | 09:17 |
frickler | ah, that'll be a major version bump, so the test release is suds-community-1.0.0b1 | 09:21 |
frickler | which I can install locally from source just fine, so that looks like progress | 09:21 |
mdbooth | dansmith: Liking DEVSTACK_PARALLEL: Speedup: 1.2226 :) | 09:27 |
sean-k-mooney[m] | it works pretty well | 09:27 |
mdbooth | It had a smaller benefit in a GCE vm, but this one on PSI seems to like it | 09:28 |
sean-k-mooney[m] | are you using the ci flavors or normal ones | 09:28 |
mdbooth | normal | 09:29 |
sean-k-mooney[m] | the normal ones are all backed by ceph and have lower iops | 09:29 |
sean-k-mooney[m] | so ya it helps more there | 09:29 |
sean-k-mooney[m] | the ci ones have local nvme storage and it benifits less | 09:29 |
sean-k-mooney[m] | the more io overhead there is the more parrallel helps | 09:30 |
opendevreview | Balazs Gibizer proposed openstack/nova master: Add a WA flag waiting for vif-plugged event during reboot https://review.opendev.org/c/openstack/nova/+/813419 | 10:15 |
sean-k-mooney | hum now that is interesting. | 10:29 |
sean-k-mooney | did people know that if you hit b in gerrit it loads git blam on the side | 10:30 |
sean-k-mooney | *blame | 10:30 |
gibi | that sounds usefull | 10:32 |
*** thelounge94 is now known as redrobot | 13:02 | |
*** redrobot is now known as thelounge94 | 13:04 | |
*** thelounge94 is now known as redrobot | 13:04 | |
dansmith | mdbooth: sweet, I have a bunch of other parallel points to add, but I need to circle back and finish them | 13:29 |
opendevreview | norman shen proposed openstack/nova master: Recreate mdev devices according to placement https://review.opendev.org/c/openstack/nova/+/810220 | 13:39 |
* bauzas disappears for kids taxi and then going to the garage | 14:21 | |
bauzas | but I'll back around 1515UTC (45 mins before the meeting) | 14:21 |
gibi | kashyap: I read the driver part of https://review.opendev.org/c/openstack/nova/+/762330 and left comments. (I still not read the test parts). I don't feel this commit is ready. If feel this is patched together in a rush. | 14:23 |
opendevreview | Alexey Stupnikov proposed openstack/nova master: Rollback problematic port bindings on source host only https://review.opendev.org/c/openstack/nova/+/813659 | 14:25 |
pslestang | sean-k-mooney: FYI it seems like there is already someone patching oslo.vmware to use suds-community instead of suds-jurko https://review.opendev.org/c/openstack/oslo.vmware/+/813377 | 14:25 |
sean-k-mooney | yes | 14:25 |
sean-k-mooney | pslestang: frickler mentioned that above | 14:26 |
pslestang | sean-k-mooney: ouup's I missed it | 14:27 |
kashyap | gibi: Hi, I'll look and investigate. The submitter told me they even tested it in a real deployment (I took their word) | 14:31 |
gibi | kashyap: I can accept that it works but for me it is really hard to follow. maybe other in the core team has more knowledge to figure out what happens. | 14:32 |
kashyap | gibi: Thanks for the review time! We definitely don't want this rushed in. And needs careful integration testing. As it impacts live migration | 14:32 |
kashyap | gibi: No, if it's hard to follow for you, that's a reason enough to clean it up. And also it needs code comments too | 14:33 |
gibi | so I'm more concerned about understandabilty now than correctness | 14:33 |
gibi | ahh, ok | 14:33 |
kashyap | Yeah; I agree this needs more explnaations | 14:33 |
gibi | lyarwood: I looked into https://bugs.launchpad.net/nova/+bug/1946339 in short I don't see what happens and I cannot reproduce it locally while it is happening on the gate frequently. I'm a bit stuck | 14:40 |
sean-k-mooney | gibi: lyarwood is hopfule preparing for an operation later today and will be recovering for the next ~2 weeks | 14:46 |
gibi | sean-k-mooney: ack, I know. I just wanted to get back to him. (I update the bug with my finding) | 14:47 |
sean-k-mooney | ah test_unshelve_offloaded_server_with_qos_port_pci_update_fails | 14:47 |
sean-k-mooney | gibi: presumable this is some interaction between artoms fix for updating the pci device slot in the port profile on unshleve and minium band with based scheduling | 14:50 |
opendevreview | Alexey Stupnikov proposed openstack/nova master: Rollback problematic port bindings on source host only https://review.opendev.org/c/openstack/nova/+/813659 | 14:50 |
sean-k-mooney | gibi: have you tried ensuring that the pci device claimied as part of the unshelve is different | 14:50 |
sean-k-mooney | e.g. boot a vm, shelve it, boot another vm ensuring it claims the same pci device as the first then try unslevleing the first vm | 14:51 |
sean-k-mooney | oh this is in the func tests | 14:52 |
sean-k-mooney | not an end user bug | 14:52 |
gibi | nope | 14:53 |
gibi | and the first exception is part of the test | 14:53 |
sean-k-mooney | so it looks like somehow the db get torwn down too early? | 14:53 |
gibi | something like that | 14:53 |
gibi | but I don't get how can that be | 14:53 |
sean-k-mooney | that is presumable created by the fixture in setup | 14:54 |
sean-k-mooney | so ya that is hard to understand | 14:54 |
sean-k-mooney | gibi: this is not messing with any global state right https://github.com/openstack/nova/blob/a8d3ab2513c39aeac3393b2154988316dfa2db3a/nova/tests/functional/test_servers_resource_request.py#L2523-L2526 | 14:56 |
sean-k-mooney | gibi: we have our own isntance of placement per test function | 14:56 |
sean-k-mooney | that has its own db | 14:56 |
gibi | I assume we have placement per test case per test executor | 14:57 |
gibi | otherwise everything would be unstable | 14:57 |
sean-k-mooney | ya that is my assumtion too | 14:57 |
gibi | btw the sriov placement tree is created in the test case setup so that is per test case for sure | 14:57 |
gibi | and the uuids shoudl be unique | 14:57 |
sean-k-mooney | could this be failing due to the update_avaiable_resouce_provier periodic task? | 15:01 |
sean-k-mooney | if that ran it would raise the same error internally but it might now catch it | 15:01 |
gibi | there is no proof in the logs that the period runs https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_b15/713498/27/check/nova-tox-functional-py38/b1582a8/job-output.txt | 15:02 |
gibi | we have test cases where we trigger the periodic manually, so I think we even turn of the periodic for the func test | 15:03 |
gibi | I cannot reproduce it even if I delay the compute side of the execution locally, the wait for server status timeouts first not the conductor | 15:10 |
gibi | so I don't get how the conductor can time out in the gate | 15:10 |
gibi | I will try pulling out the test execution order from a failed gate run and see if that reproduce it locally or not.. | 15:12 |
sean-k-mooney | your referign to "oslo_messaging.exceptions.MessagingTimeout: No reply on topic conductor\n" | 15:13 |
gibi | yepp | 15:13 |
sean-k-mooney | this is also using the in memory driver so there is no networking issues that could be at play | 15:14 |
sean-k-mooney | with that said do you know what we set the time out too | 15:14 |
sean-k-mooney | we make spawn and other thing synconouse in the functional tests | 15:14 |
sean-k-mooney | i wonder if we only see this in a slow node | 15:15 |
sean-k-mooney | like is the time out 1 second of something tiny like that | 15:15 |
sean-k-mooney | when using the fake driver | 15:15 |
gibi | I don't know the timeout value in the funct test, but I put a sleep(10) in the compute side just before raising the expected exception, and it makes the test waiting for the server state time out instead of the fake driver | 15:15 |
sean-k-mooney | so i think this is where that messaging timeout gets raised https://github.com/openstack/oslo.messaging/blob/ca939fc0e4683efce87b567a9a074063a9c75b4f/oslo_messaging/_drivers/impl_fake.py#L207-L214 | 15:20 |
sean-k-mooney | which happend due to a _queue.Empty from return self.greenlet.switch() | 15:21 |
sean-k-mooney | the resource provider error on the compute was boubled up all the way to the rpc server | 15:22 |
sean-k-mooney | that first traceback is form here https://github.com/openstack/oslo.messaging/blob/ca939fc0e4683efce87b567a9a074063a9c75b4f/oslo_messaging/rpc/server.py#L178-L180 | 15:25 |
gibi | but that line is visible in case of a successful run too | 15:26 |
sean-k-mooney | well after that message is printed we sent the failure to the conductor/api here https://github.com/openstack/oslo.messaging/blob/ca939fc0e4683efce87b567a9a074063a9c75b4f/oslo_messaging/rpc/server.py#L186 | 15:27 |
sean-k-mooney | would that be recied by https://github.com/openstack/nova/blob/master/nova/conductor/api.py#L140-L141 ? | 15:29 |
gibi | this is the log from a successful run https://paste.opendev.org/show/809928/ | 15:29 |
sean-k-mooney | no it would be in the conductor maager https://github.com/openstack/nova/blob/fdfdba265833d237e22676f9a223ab8ca0fe1e03/nova/conductor/manager.py#L941 | 15:29 |
sean-k-mooney | gibi: right so in that case we see more output in the python loggin capture | 15:30 |
sean-k-mooney | where as ehre it stops and we get stderr | 15:31 |
gibi | sean-k-mooney: it is strange, the timeout is from self.compute_task_api.build_instances not from unshelve_instance | 15:31 |
sean-k-mooney | build instance? | 15:32 |
sean-k-mooney | so here https://github.com/openstack/nova/blob/a8d3ab2513c39aeac3393b2154988316dfa2db3a/nova/tests/functional/test_servers_resource_request.py#L2533-L2534 | 15:32 |
sean-k-mooney | oh | 15:32 |
sean-k-mooney | we mess withthe name before we boot the vm | 15:32 |
sean-k-mooney | are we somethimes landing on host2 | 15:32 |
sean-k-mooney | we are not forcing it to boot on host1 | 15:33 |
gibi | we request to land on host1 first https://github.com/openstack/nova/blob/a8d3ab2513c39aeac3393b2154988316dfa2db3a/nova/tests/functional/test_servers_resource_request.py#L554 | 15:33 |
gibi | in the meantime I confirm that it is not about testcase ordering. the same order that failed on the gate passing for me locally | 15:35 |
gibi | I don't get how can we fail on the build_instance so late | 15:37 |
gibi | the VM went to active according to the test | 15:37 |
gibi | shit is it is a reschedule | 15:39 |
gibi | that calls back to build_instance | 15:39 |
gibi | File "/home/zuul/src/opendev.org/openstack/nova/nova/compute/manager.py", line 2263, in _do_build_and_run_instance | 15:39 |
sean-k-mooney | ya i was just checkign that we dont use build an drun instance in unshelve which we dont we use driver.spawn | 15:41 |
sean-k-mooney | https://github.com/openstack/nova/blob/fdfdba265833d237e22676f9a223ab8ca0fe1e03/nova/compute/manager.py#L6675 | 15:41 |
sean-k-mooney | gibi: you think for some reason it did not boot on host1 and reschduled to host2 | 15:41 |
sean-k-mooney | we could tetst this by disabling host1 and see if that cause the error | 15:42 |
sean-k-mooney | we shoudl see the schduler select the host though right | 15:42 |
gibi | I can test that | 15:43 |
gibi | if I disable host1 at the start of the test case then the initial boot will fail and the VM is in ERROR state | 15:45 |
gibi | * initial boot fails | 15:45 |
sean-k-mooney | \noslo_messaging.exceptions.MessagingTimeout: No reply on topic conductor\n', 'host2') | 15:45 |
gibi | so the test forces the VM to host1 | 15:45 |
sean-k-mooney | the message time out was for host 2 | 15:45 |
gibi | could it be that # make host1 unusable so the subsequent unshelve needs to select host2 | 15:45 |
gibi | self.admin_api.put_service( | 15:45 |
gibi | self.compute1_service_id, {"status": "disabled"}) | 15:45 |
gibi | sorry | 15:45 |
gibi | coudl it be that https://github.com/openstack/nova/blob/fdfdba265833d237e22676f9a223ab8ca0fe1e03/nova/tests/functional/test_servers_resource_request.py#L2548 does not disable the host quickly enough and ushelve selects host1? | 15:46 |
gibi | hm, but why host2 is the call, true | 15:47 |
* bauzas is back | 15:47 | |
bauzas | quick reminder | 15:47 |
bauzas | nova meeting in 12-ish minutes in this channel | 15:48 |
sean-k-mooney | its posible although that is ment to be a blocking call | 15:49 |
sean-k-mooney | gibi: have you tied inverting the logic an disbaling host2 instead of host one | 15:50 |
sean-k-mooney | here https://github.com/openstack/nova/blob/a8d3ab2513c39aeac3393b2154988316dfa2db3a/nova/tests/functional/test_servers_resource_request.py#L2548-L2549 | 15:50 |
gibi | so change the test from boot:host1, shelve offload, unshelve:host2 -> to boot:host2, shelve offload, unshelve:host1 / | 15:50 |
sean-k-mooney | you could be right that we are racing with that disabel and we neeed to add a get | 15:50 |
gibi | ? | 15:50 |
sean-k-mooney | no i ment use replace self.compute1_service_id with self.compute2_service_id | 15:51 |
gibi | I cannot simply disable host2 as we need to unshelve on a compute where the placement RP tree is wrong | 15:51 |
sean-k-mooney | here https://github.com/openstack/nova/blob/a8d3ab2513c39aeac3393b2154988316dfa2db3a/nova/tests/functional/test_servers_resource_request.py#L2548-L2549 | 15:51 |
sean-k-mooney | so it unshelve to the same hsot | 15:51 |
bauzas | gibi: sean-k-mooney: discussing about https://bugs.launchpad.net/nova/+bug/1946339 ? | 15:51 |
gibi | bauzas: yes | 15:52 |
sean-k-mooney | right i know it would break the test logic | 15:52 |
bauzas | ack thanks | 15:52 |
sean-k-mooney | but im wondering if some how we are not landing on host 2 | 15:52 |
sean-k-mooney | e.g. to confirm your assertion that perhaps the disabel is not working | 15:52 |
sean-k-mooney | we might need a wait before the unshleve | 15:52 |
gibi | if I just disable host2 then the test times out at https://github.com/openstack/nova/blob/a8d3ab2513c39aeac3393b2154988316dfa2db3a/nova/tests/functional/test_servers_resource_request.py#L2558 as no expcetion happens host1 can unshelve the instance | 15:54 |
sean-k-mooney | we should be abel to assert the service is disabeld form the responce https://docs.openstack.org/api-ref/compute/?expanded=update-compute-service-detail#update-compute-service | 15:55 |
gibi | yeah that would only help if I could reproduce the problem | 15:58 |
gibi | checking the response | 15:58 |
gibi | I still have to track down why could we re-schedule | 15:58 |
bauzas | #startmeeting nova | 16:00 |
opendevmeet | Meeting started Tue Oct 12 16:00:01 2021 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
opendevmeet | The meeting name has been set to 'nova' | 16:00 |
bauzas | hola folks | 16:00 |
bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:00 |
gibi | o/ | 16:00 |
sean-k-mooney | o/ | 16:00 |
gmann | o/ | 16:01 |
elodilles | o/ | 16:01 |
bauzas | ok, let's start | 16:01 |
bauzas | #topic Bugs (stuck/critical) | 16:02 |
bauzas | No Critical bug | 16:02 |
bauzas | #link 18 new untriaged bugs (+5 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New | 16:02 |
bauzas | sorry I didn't had to triage the bugs this week, will do that tomorrow | 16:02 |
bauzas | any bug to discuss ? | 16:03 |
bauzas | ok, looks not | 16:04 |
bauzas | #topic Gate status | 16:04 |
bauzas | Nova gate bugs #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure | 16:04 |
bauzas | I saw gibi and sean-k-mooney discussing about one of them | 16:04 |
bauzas | folks, do you want to discuss about this now or off the meeting ? | 16:04 |
bauzas | context : https://bugs.launchpad.net/nova/+bug/1946339 | 16:04 |
sean-k-mooney | i think off meeting | 16:04 |
gibi | I have nothing specific to say :) | 16:04 |
bauzas | cool, moving on then | 16:05 |
gibi | still trying to reproduce / understand what happens | 16:05 |
sean-k-mooney | im still reviewing the logs and trying to repoduce | 16:05 |
bauzas | acvk | 16:05 |
bauzas | Placement periodic job status #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly | 16:05 |
bauzas | so you'll see we have a problem with one job | 16:05 |
bauzas | placement-nova-tox-functional-py38 | 16:05 |
gibi | https://zuul.openstack.org/build/055ea1806bf14b1994f1ebdcee720134/log/job-output.txt#808 | 16:07 |
gibi | strange | 16:07 |
gibi | ubuntu-focal | /bin/sh: 1: Syntax error: "(" unexpected | 16:07 |
bauzas | it looks to me the tox call is wrong | 16:07 |
bauzas | I guess because of the regex | 16:07 |
bauzas | have we modified this ? | 16:07 |
bauzas | /home/zuul/.local/tox/bin/tox --showconfig -efunctional-py38 ^((?!(?:api|notification)_sample_tests|functional\.db\.).)*$ > /tmp/ansible.quewmudg | 16:07 |
gibi | I'm not waware of any modification recently | 16:08 |
bauzas | I need to take time to look at the regex | 16:08 |
bauzas | to verify whether it works | 16:08 |
gibi | we touched tox.ini in febr | 16:08 |
gibi | that was a looong time ago | 16:08 |
* bauzas uses https://regex101.com/ | 16:09 | |
bauzas | the regex looks valid to me | 16:09 |
gmann | does not seems like any recent change in openstack-tox-functional-py38 base job too | 16:11 |
dansmith | that has to be something not in tox.init right? | 16:11 |
gmann | yea | 16:12 |
dansmith | that "get tox envlist config" is some chunk of inlined bash from ansible right/ | 16:12 |
bauzas | yes | 16:12 |
bauzas | https://zuul.openstack.org/build/055ea1806bf14b1994f1ebdcee720134/log/job-output.txt#807 | 16:12 |
dansmith | right | 16:12 |
bauzas | that's when calling /home/zuul/.local/tox/bin/tox --showconfig -efunctional-py38 ^((?!(?:api|notification)_sample_tests|functional\.db\.).)*$ > /tmp/ansible.quewmudg | 16:12 |
bauzas | we get a stdout telling "/bin/sh: 1: Syntax error: "(" unexpected" | 16:12 |
sean-k-mooney | has anyone just tried runnign the func test locally | 16:13 |
gibi | yes | 16:13 |
bauzas | not yet | 16:13 |
gibi | it work for me | 16:13 |
bauzas | that's placement so we can't create a LP bug, but I'd appreciate if we could track in down | 16:13 |
bauzas | track it* down | 16:13 |
bauzas | I'm not used to storyboard honestly | 16:14 |
bauzas | but I guess this is time for me to fly | 16:15 |
gibi | it is not hard it is just slow :) | 16:15 |
gmann | very slow :) | 16:15 |
dansmith | and hard :) | 16:15 |
bauzas | well, this is not that's hard, it's just a new foreign language for me to understand :) | 16:16 |
* bauzas wonders whether someone will provide a Duolingo feature for Storyboard language | 16:16 | |
bauzas | but I can create a "bug" | 16:17 |
sean-k-mooney | or you know we could just move it to launchpad | 16:17 |
gmann | +1 | 16:17 |
sean-k-mooney | since it now part of the comptue project deliverables | 16:17 |
bauzas | sean-k-mooney: please don't make my dreams tru | 16:17 |
bauzas | true* | 16:17 |
bauzas | honestly, who's looking at the storyboard stories we have for placement ? | 16:17 |
bauzas | I don't :shame: | 16:18 |
opendevreview | Balazs Gibizer proposed openstack/placement master: DNM: check tox func job https://review.opendev.org/c/openstack/placement/+/813670 | 16:18 |
gibi | let see if it still fails ^^ | 16:18 |
bauzas | gibi: thanks | 16:18 |
gmann | gibi: I do not think it will start jobs unless you change any file | 16:18 |
bauzas | I'll create the SB task and let's dissuss this later | 16:19 |
gmann | that is what we got error from zuul last week | 16:19 |
bauzas | moving on ? | 16:19 |
gibi | gmann: it seems it is https://zuul.opendev.org/t/openstack/status#813670 | 16:19 |
gibi | bauzas: yes | 16:19 |
gmann | ah interesting. | 16:20 |
bauzas | k, let's continue | 16:20 |
bauzas | oh, wait then | 16:20 |
bauzas | gmann: we're all listening to you :) | 16:20 |
gmann | ah, we can move. I will check in parallel | 16:20 |
bauzas | gmann: ok, as you prefer | 16:21 |
bauzas | moving on then | 16:21 |
bauzas | (we can continue to discuss this bug in the open discussion if people want and we have time) | 16:21 |
bauzas | #topic Release Planning | 16:22 |
bauzas | Nova 24.0.0 is now released \o/ | 16:22 |
bauzas | of course, placement too | 16:22 |
bauzas | thanks to all the people who contributed to it | 16:22 |
bauzas | now, we're officially in the Yoga timeframe, even if master is on Yoga since 3 weeks :) | 16:23 |
bauzas | that makes me go to the next deadline | 16:23 |
bauzas | Yoga-1 is due Nova 18th #link https://releases.openstack.org/yoga/schedule.html#y-1 | 16:23 |
bauzas | I just wrote something in the PTG agenda about discussing our own deadlines | 16:25 |
bauzas | and whether we should do feature or specs freeze | 16:25 |
bauzas | not wanting to discuss it by now | 16:25 |
bauzas | but start to think about this | 16:25 |
bauzas | we're a bit early in the cycle so a Spec review day is not really important to discuss by now | 16:26 |
bauzas | unless people disagree | 16:26 |
bauzas | we don't have a lot of open specs by now | 16:27 |
bauzas | anyone anything ? | 16:28 |
bauzas | for release planning ? | 16:28 |
gibi | bauzas: there is two move implemented specs patch https://review.opendev.org/q/project:openstack/nova-specs+status:open | 16:28 |
gibi | one from you and one from brin | 16:29 |
opendevreview | Jan Hartkopf proposed openstack/nova master: docs: add hint to create folder for new microversion https://review.opendev.org/c/openstack/nova/+/813672 | 16:29 |
bauzas | oh that's fun | 16:29 |
bauzas | gibi: good catch, will close mine as it's the newest | 16:29 |
bauzas | but I'm not sure brin got all the things | 16:29 |
bauzas | anyway, let's not discuss this now | 16:30 |
gibi | ack | 16:31 |
bauzas | #topic Review priorities | 16:31 |
bauzas | https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement)+label:Review-Priority%252B1 | 16:31 |
bauzas | still continuing to use this flag for tracking changes I wanna review | 16:32 |
bauzas | moving on, we'll discuss the flag usage at the PTG | 16:32 |
bauzas | #topic PTG Planning | 16:33 |
bauzas | every info is in the PTG etherpad #link https://etherpad.opendev.org/p/nova-yoga-ptg | 16:33 |
bauzas | important : | 16:33 |
bauzas | Last week before the PTG, please prepare your points by Thursday EOB so bauzas can provide a nova PTG agenda | 16:33 |
bauzas | (that's an ideal thing) | 16:33 |
bauzas | I'll start moving things around on Friday in order to group related things (if I can) | 16:34 |
bauzas | of course, we'll surely have last minute topics to discuss :) | 16:34 |
bauzas | neutron PTL ( lajoskatona ) seemed interested in some x-p session, we need to find a slot | 16:34 |
bauzas | I just got a email before the meeting from rosmaita about a proposed cinder x-p session slot on Thursday 1pm UTC | 16:35 |
bauzas | wfy ? | 16:35 |
gibi | works for me, early for the US folks | 16:37 |
opendevreview | Balazs Gibizer proposed openstack/nova master: DNM: add traces to troubleshoot bug/1946339 https://review.opendev.org/c/openstack/nova/+/813674 | 16:38 |
bauzas | brian is telling that they have 1pm-2.30pm free | 16:38 |
bauzas | so I guess dansmith could join at 1.30pm if he wishes but for melwitt, yeah that could be tough | 16:39 |
dansmith | meaning 1330Z ? | 16:39 |
bauzas | yeah we could start at this time | 16:39 |
bauzas | the two things he had to discuss was : | 16:40 |
dansmith | yeah that's the absolute earliest for me without a special arrangement, | 16:40 |
bauzas | https://blueprints.launchpad.net/cinder/+spec/add-volume-re-image-api | 16:40 |
bauzas | https://blueprints.launchpad.net/nova/+spec/volume-backed-server-rebuild | 16:40 |
dansmith | but not sure I need to be there specifically | 16:40 |
dansmith | ah | 16:40 |
bauzas | I'll try to see if we can get some later slot | 16:40 |
bauzas | melwitt could be interested in one of the two topics | 16:41 |
dansmith | well, like I say, I'll be available at that time, but.. ack | 16:41 |
bauzas | if not the two :) | 16:41 |
bauzas | melwitt: around ? | 16:41 |
bauzas | dansmith: ack, we'll see how this goes | 16:42 |
bauzas | the problem here is that I think both specs are pretty large | 16:42 |
bauzas | they're actually tied | 16:42 |
bauzas | ok, let's move on from this topic, time is flying but I'll see what we can do | 16:43 |
bauzas | the fact is, we'll be missing lyarwood and I'd appreciate if some other volume experts to be there | 16:43 |
bauzas | moving on | 16:44 |
bauzas | #topic Stable Branches | 16:44 |
bauzas | elodilles: floor is yours | 16:44 |
elodilles | let me copy from the meeting page :) | 16:45 |
elodilles | old stable gates are blocked (stein and older), needs the setuptools pinning patch to unblock: https://review.opendev.org/q/I26b2a14e0b91c0ab77299c3e4fbed5f7916fe8cf | 16:45 |
elodilles | Wallaby (23.1.0), Victoria (22.3.0), Ussuri (21.2.3) were released last week | 16:46 |
elodilles | Ussuri Extended Maintenance transition is in a month (Nov 12) - do we want to prepare another release? -- https://etherpad.opendev.org/p/nova-stable-ussuri-em | 16:46 |
elodilles | that was it | 16:46 |
elodilles | since we just released from stable/ussuri I don't know whether we need another release before the transition | 16:47 |
elodilles | but if anyone see any patch that would be good to release then let us know | 16:47 |
bauzas | do we have backports to look at ? | 16:47 |
elodilles | we have lots of backports on ussuri | 16:48 |
elodilles | they are listed on the pad: https://etherpad.opendev.org/p/nova-stable-ussuri-em | 16:48 |
bauzas | yeah I can see them | 16:48 |
bauzas | https://review.opendev.org/q/project:openstack/nova+branch:stable/ussuri+is:open | 16:48 |
bauzas | humpf | 16:49 |
elodilles | I went through the patches and commented on the etherpad for some | 16:49 |
bauzas | I guess one last release would be appreciated | 16:49 |
bauzas | before we call it EM | 16:49 |
elodilles | there are some that needs a second +2 only | 16:49 |
bauzas | elodilles: we can make some kind of status updates at the meetings | 16:50 |
elodilles | bauzas: sure, I'll prepare with that | 16:50 |
bauzas | elodilles: and ping me and a few other stable cores to look at ussuri this week and the week after PTG | 16:50 |
elodilles | ack | 16:50 |
bauzas | #topic Sub/related team Highlights | 16:50 |
bauzas | Libvirt (lyarwood) | 16:51 |
bauzas | lyarwood is not there, nothing to mention | 16:51 |
bauzas | let's move straight to the last bit of the agenda | 16:51 |
bauzas | #topic Open discussion | 16:51 |
bauzas | Next week meeting to be cancelled (PTG). AgreedĀ ? | 16:51 |
gibi | agre | 16:51 |
gibi | e | 16:51 |
bauzas | anyone disagreeing ? | 16:51 |
bauzas | 1.. | 16:51 |
bauzas | 2.. | 16:51 |
bauzas | 3.. | 16:52 |
bauzas | OK, that's it, will send the email | 16:52 |
bauzas | I'm done with the agenda now, anyone wanting to raise anything ? | 16:52 |
bauzas | we have 8 mins in the balance :) | 16:52 |
gibi | just circle back to the placement functional failure | 16:53 |
bauzas | wfm | 16:53 |
gibi | it still visible on master | 16:53 |
bauzas | gmann: you had thoughts ? | 16:53 |
gibi | and I do belive this causing https://opendev.org/zuul/zuul-jobs/commit/c02c28a982da8d5a9e7b4ca38d30967f6cd1531d | 16:53 |
gmann | I think this is because of https://opendev.org/zuul/zuul-jobs/commit/c02c28a982da8d5a9e7b4ca38d30967f6cd1531d | 16:53 |
gibi | that we include the regexp to the call | 16:53 |
gmann | gibi: ah you are fast | 16:53 |
gibi | we simply not need the regexp in that call | 16:53 |
gibi | or we need to quote it | 16:54 |
gibi | but I don't know how to feed this back to zuul | 16:54 |
gibi | gmann: :) | 16:54 |
gmann | I think bext way is not to include the test regex in tox_extra_args and instead add it as part of command itself | 16:55 |
gmann | best | 16:55 |
gmann | let me try that | 16:55 |
gibi | gmann: ack, we can even left out the regexp param that is not needed for the --showconfig call I think | 16:56 |
bauzas | gmann: gibi: thanks for the findings | 16:56 |
gibi | I have nothing else for today | 16:56 |
gmann | yeah, tox_extra_args purpose is completely separate then test regex | 16:56 |
gibi | gmann: ack | 16:56 |
sean-k-mooney | we normally do that with posargs like this https://github.com/openstack/placement/blob/master/tox.ini#L40 | 16:57 |
gmann | yeah | 16:57 |
sean-k-mooney | then invoke tox like "tox -e fucntional -- <regex goes here>" | 16:57 |
sean-k-mooney | i think we can likely close the meeting there | 16:59 |
bauzas | yeah I was about to say | 16:59 |
bauzas | we can continue off meeting | 16:59 |
bauzas | let me call it done | 16:59 |
bauzas | #endmeeting | 16:59 |
opendevmeet | Meeting ended Tue Oct 12 16:59:40 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:59 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-10-12-16.00.html | 16:59 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-10-12-16.00.txt | 16:59 |
opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-10-12-16.00.log.html | 16:59 |
bauzas | thanks all | 16:59 |
gibi | bauzas: thanks! | 16:59 |
sean-k-mooney | gibi: for https://bugs.launchpad.net/nova/+bug/1946339 i think we are getting to here but i never see log lings corresponding to https://github.com/openstack/nova/blob/a8d3ab2513c39aeac3393b2154988316dfa2db3a/nova/tests/functional/test_servers_resource_request.py#L2568-L2574 | 17:00 |
bauzas | gibi: thanks for spotting the root cause while I was deblatering for some paperwork :) | 17:00 |
gibi | sean-k-mooney: yeah but that becuase we fail at the assert https://github.com/openstack/nova/blob/a8d3ab2513c39aeac3393b2154988316dfa2db3a/nova/tests/functional/test_servers_resource_request.py#L2560\ | 17:06 |
sean-k-mooney | are you sure about that we might be | 17:08 |
sean-k-mooney | i did not see that in the log as explcitly failing | 17:08 |
sean-k-mooney | did i miss that | 17:08 |
gibi | I'm looking at this https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_b15/713498/27/check/nova-tox-functional-py38/b1582a8/job-output.txt | 17:09 |
gibi | it has | 17:09 |
gibi | 2021-10-08 01:21:54.733579 | ubuntu-focal | testtools.matchers._impl.MismatchError: 'UnexpectedResourceProviderNameForPCIRequest' != 'DBNonExistentTable' | 17:09 |
sean-k-mooney | ah right | 17:09 |
sean-k-mooney | error_notification = self.notifier.wait_for_versioned_notifications( | 17:11 |
sean-k-mooney | 'compute.exception')[0] | 17:11 |
sean-k-mooney | we are just takign the first error | 17:11 |
gibi | yepp | 17:11 |
gibi | I have to drop for today | 17:11 |
sean-k-mooney | could it be the order of the excption could change and we get more then one | 17:12 |
sean-k-mooney | ok | 17:12 |
gibi | I pushed a small patch with an extra log seeing what triggers the reschedule | 17:12 |
gibi | https://review.opendev.org/c/openstack/nova/+/813674 | 17:12 |
sean-k-mooney | im not sure there is a reschdule | 17:12 |
sean-k-mooney | but cool lets see what that shows | 17:12 |
sean-k-mooney | ill play with a bit locally | 17:12 |
gibi | this line in the stack trace File "/home/zuul/src/opendev.org/openstack/nova/nova/compute/manager.py", line 2263, in _do_build_and_run_instance | 17:13 |
gibi | points to a reschedule for me | 17:13 |
gibi | anyhow leaving now. thanks for the shared thinking | 17:14 |
gibi | o/ | 17:14 |
sean-k-mooney | hum | 17:19 |
sean-k-mooney | ERROR: Cannot install jsonschema>=3.2.0, openstack-placement==1.0.0 and openstack-placement==1.1.0 because these package versions have conflicting dependencies. | 17:19 |
sean-k-mooney | The conflict is caused by: | 17:19 |
sean-k-mooney | The user requested jsonschema>=3.2.0 | 17:19 |
sean-k-mooney | openstack-placement 1.1.0 depends on jsonschema<3.0.0 and >=2.6.0 | 17:19 |
sean-k-mooney | The user requested jsonschema>=3.2.0 | 17:19 |
sean-k-mooney | openstack-placement 1.0.0 depends on jsonschema<3.0.0 and >=2.6.0 | 17:19 |
sean-k-mooney | The user requested (constraint) jsonschema===3.2.0 | 17:20 |
sean-k-mooney | that was form trying to run nova func test on master | 17:20 |
sean-k-mooney | it cant create the pip env | 17:20 |
sean-k-mooney | placmenet required >=3.2.0 | 17:21 |
sean-k-mooney | https://github.com/openstack/placement/blob/master/requirements.txt#L10 | 17:21 |
sean-k-mooney | which is the same as uc https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L547 | 17:23 |
sean-k-mooney | oh | 17:24 |
sean-k-mooney | this is the same suds-jurko issue | 17:24 |
sean-k-mooney | ok i just need to locally comment out oslo.vmware in our test-requirements.txt until that is fixed | 17:25 |
opendevreview | Ghanshyam proposed openstack/nova master: Define new functional test tox env for placement gate to run https://review.opendev.org/c/openstack/nova/+/813679 | 17:33 |
opendevreview | Ghanshyam proposed openstack/placement master: Use 'placement-nova-functional-py38' tox env for placement nova job https://review.opendev.org/c/openstack/placement/+/813680 | 17:36 |
opendevreview | Ghanshyam proposed openstack/nova master: Define new functional test tox env for placement gate to run https://review.opendev.org/c/openstack/nova/+/813679 | 18:11 |
opendevreview | Ghanshyam proposed openstack/nova master: Define new functional test tox env for placement gate to run https://review.opendev.org/c/openstack/nova/+/813679 | 18:13 |
gmann | gibi: bauzas these fix the placement-nova functional job - https://review.opendev.org/q/topic:%22fix-placement-gate%22+(status:open%20OR%20status:merged) | 19:06 |
opendevreview | sean mooney proposed openstack/nova master: [WIP] adress intermitent failure of functional tests https://review.opendev.org/c/openstack/nova/+/813695 | 19:08 |
sean-k-mooney | gibi: i think ^ would fix https://bugs.launchpad.net/nova/+bug/1946339 | 19:09 |
*** efried1 is now known as efried | 19:31 | |
simondodsley | How would I achieve full disaster recovery of nova instances from one OS cluster to another? I can replicate Cinder volumes to another cluster (sort of), but I can't find a way to replicate the nova instances? I know Stratoscale used to do something like this, but they are dead now. Any other ways to do this? | 21:09 |
melwitt | simondodsley: I can't answer your question, I'm sure there are a lot of ways to do it, but you might get some ideas from this project https://docs.openstack.org/freezer/latest/ this is/was the openstack project for disaster recovery. it hasn't had activity for the past year or so, it may no longer be maintained https://github.com/openstack/freezer-dr | 21:21 |
opendevreview | Ade Lee proposed openstack/nova master: Add check job for FIPS https://review.opendev.org/c/openstack/nova/+/790519 | 21:53 |
gmann | melwitt: dansmith please check these two to unblock the placement gate https://review.opendev.org/q/topic:%22fix-placement-gate%22+(status:open%20OR%20status:merged) | 22:04 |
melwitt | gmann: hm, not sure I understand the solution. it doesn't seem right to define any placement env in the nova repo? I also don't understand why the current setup is failing | 22:29 |
gmann | melwitt: as it is used in nova-placement job we can move the job definition also on nova side but that run only in placement | 22:31 |
melwitt | gmann: I don't understand why the current thing is no longer working, it was intended to be able to use the nova-tox-functional-py38 in other projects right? as a parent job? | 22:32 |
melwitt | why do we need to add nova-placement in the nova or placement repo now? | 22:32 |
melwitt | let me read the commit message and referenced zuul commit again | 22:35 |
gmann | melwitt: placement-nova-tox-functional-py38 job is only needed to skip the sample and db tests otherwise same as nova-tox-functional-py38 | 22:35 |
gmann | and I think these tests are skipped as they do not use placement_fixture | 22:35 |
melwitt | yeah, I see that ... trying to understand the bug and why we can't use the parent job as intended | 22:36 |
melwitt | so a recent commit added tox_extra_args back, apparently previously it wasn't being used even though it was defined in the placement .zuul.yaml I guess | 22:37 |
melwitt | and now that it's being used, there's a syntax error happening | 22:37 |
gmann | melwitt: it is now started failing because test regex to skip the test is defined in tox_extra_args which is now added in 'Get tox envlist config; tasks https://opendev.org/zuul/zuul-jobs/commit/c02c28a982da8d5a9e7b4ca38d30967f6cd1531d | 22:37 |
gmann | yes | 22:37 |
gmann | I do not think tox_extra_args should be used for tests regex formation instead we should define the test path/regex etc in tox env command itself | 22:38 |
gmann | and as tox env has to live in nova and job is defined in placement, we need these two repo changes to fix it | 22:39 |
melwitt | oh... at least to me it looks like it makes sense for the regex string to be an extra arg to tox | 22:39 |
gmann | but that fail when we take tox_extra_args in tox env with no tests run like this https://opendev.org/zuul/zuul-jobs/commit/c02c28a982da8d5a9e7b4ca38d30967f6cd1531d | 22:40 |
gmann | which is generic to add tox_extra_args because it can have more config things for tox | 22:41 |
gmann | melwitt: easy way is to just run nova-tox-functional-py38 and do not skip tests as it is periodic weekly job | 22:41 |
melwitt | sorry, I got lost at the "no tests run" and "skip tests" | 22:42 |
gmann | or define the placement-nova-tox-functional-py38 job in nova but use in placement only | 22:42 |
gmann | melwitt: no test run when tox is run to show config --showconfig that is where it is failing when tox_extra_args has the test regex string | 22:45 |
melwitt | ok, I see now the "name: Run tox without tests" that is what doesn't work with the regex as an extra arg I take it | 22:45 |
gmann | melwitt: here too when for cinfig https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/tox/tasks/siblings.yaml#L22 | 22:46 |
melwitt | yeah... I see now | 22:47 |
melwitt | thanks | 22:48 |
gmann | if having tox env but not used on nova is confusing then we can move job definition too in nova but run in placement only | 22:50 |
gmann | otherwise running nova-tox-functional-py38 itself is not so costly as this will be run periodic weekly only | 22:50 |
melwitt | I dunno if it's confusing to most, it was just unintuitive to me because normally we can keep things separate and inherit from one project to another but I see now why this isn't possible with the regex we need to use. none of the zuul tox role variables are appropriate for this | 22:52 |
gmann | yeah | 22:54 |
melwitt | I think the way you have proposed probably makes the most sense | 22:55 |
melwitt | (what you have already proposed patches) | 22:55 |
gmann | ok, I added about which job is using this tox in its description to make it clear for future | 22:56 |
melwitt | yeah that is good ++ | 22:57 |
gmann | ok | 23:01 |
dansmith | gmann: each tox env is just a new target that does what we want the other job to do, is that right? | 23:07 |
dansmith | meaning, nova defines a placement env so placement can run nova tests "the placement way" ? | 23:08 |
dansmith | I think it would be super less confusing if the tox env name didn't have the other project in it, but described the difference, like "functional-all-but-foo-tests" or something | 23:08 |
melwitt | that's a good point ^ | 23:09 |
gmann | dansmith: ok | 23:09 |
gmann | placement does not need to be in name itself | 23:09 |
dansmith | I mean, just MHO, but.. seems more intuitive to me | 23:10 |
gmann | how about this 'functional-skip-sample-db-tests' | 23:11 |
melwitt | yeah maybe like functional-without-sample-tests-py38 or something | 23:11 |
melwitt | I agree, I think it would be more intuitive | 23:11 |
dansmith | cha | 23:11 |
melwitt | gmann: that sounds good, add -py38 at the end though right since it's 3.8 only? | 23:12 |
gmann | functional-without-sample-db-tests ? as it skip db test too and remove py38 thing as it can lengthy the name | 23:12 |
melwitt | oh | 23:12 |
gmann | melwitt: i was thinking just to run it on available py version as goal is not test py version in this job ? | 23:12 |
gmann | and we do not need to rename when we move to py39 or so | 23:13 |
melwitt | gmann: yeah true | 23:13 |
melwitt | yeah that makes sense | 23:13 |
gmann | ok, let me rename it. | 23:13 |
melwitt | k. will re +2 them after | 23:14 |
gmann | dansmith: melwitt do you think to move job definition also to nova side or it is ok? | 23:14 |
melwitt | gmann: I think the job def in placement is better, personally | 23:15 |
gmann | ok | 23:16 |
opendevreview | Ghanshyam proposed openstack/placement master: Use 'placement-nova-functional-py38' tox env for placement nova job https://review.opendev.org/c/openstack/placement/+/813680 | 23:23 |
opendevreview | Ghanshyam proposed openstack/nova master: Define new functional test tox env for placement gate to run https://review.opendev.org/c/openstack/nova/+/813679 | 23:23 |
gmann | melwitt: dansmith ^^ updated | 23:25 |
dansmith | I didn't see a job def change | 23:26 |
gmann | dansmith: you mean for tox env rename or you were talking to change job name too ? | 23:28 |
gmann | https://review.opendev.org/c/openstack/placement/+/813680/2/.zuul.yaml | 23:28 |
gmann | dansmith: ^^ | 23:28 |
dansmith | gmann: I dunno you asked what I thought about a job def change.. I think the placement-runs-nova-functional job probably best belongs in placement itself | 23:34 |
dansmith | which it looks like is the case | 23:35 |
gmann | yeah. | 23:35 |
gmann | let's keep it there | 23:35 |
dansmith | doesn't the placement one need to depends-on the nova one? | 23:35 |
opendevreview | Ghanshyam proposed openstack/placement master: Use 'functional-without-sample-db-tests' tox env for placement nova job https://review.opendev.org/c/openstack/placement/+/813680 | 23:37 |
gmann | dansmith: yeah, it is depends-on | 23:37 |
gmann | melwitt: ^^ updated commit msg | 23:37 |
dansmith | sorry, I dunno what I was missing | 23:38 |
dansmith | gmann: sorry had the first patch open in two tabs I think | 23:38 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!