Earlier  
Posted Nick Remark
#openstack-nova - 2021-10-12
22:32:32 melwitt why do we need to add nova-placement in the nova or placement repo now?
22:35:28 melwitt let me read the commit message and referenced zuul commit again
22:35:30 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:52 gmann and I think these tests are skipped as they do not use placement_fixture
22:36:00 melwitt yeah, I see that ... trying to understand the bug and why we can't use the parent job as intended
22:37:17 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:29 melwitt and now that it's being used, there's a syntax error happening
22:37:39 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:48 gmann yes
22:38:29 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:39:08 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:44 melwitt oh... at least to me it looks like it makes sense for the regex string to be an extra arg to tox
22:40:36 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:41:16 gmann which is generic to add tox_extra_args because it can have more config things for tox
22:41:50 gmann melwitt: easy way is to just run nova-tox-functional-py38 and do not skip tests as it is periodic weekly job
22:42:21 melwitt sorry, I got lost at the "no tests run" and "skip tests"
22:42:34 gmann or define the placement-nova-tox-functional-py38 job in nova but use in placement only
22:45:23 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:25 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:46:51 gmann melwitt: here too when for cinfig https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/tox/tasks/siblings.yaml#L22
22:47:26 melwitt yeah... I see now
22:48:11 melwitt thanks
22:50:08 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:52 gmann otherwise running nova-tox-functional-py38 itself is not so costly as this will be run periodic weekly only
22:52:55 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:54:48 gmann yeah
22:55:29 melwitt I think the way you have proposed probably makes the most sense
22:55:33 melwitt (what you have already proposed patches)
22:56:52 gmann ok, I added about which job is using this tox in its description to make it clear for future
22:57:46 melwitt yeah that is good ++
23:01:38 gmann ok
23:07:51 dansmith gmann: each tox env is just a new target that does what we want the other job to do, is that right?
23:08:08 dansmith meaning, nova defines a placement env so placement can run nova tests "the placement way" ?
23:08:37 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:09:01 melwitt that's a good point ^
23:09:04 gmann dansmith: ok
23:09:12 gmann placement does not need to be in name itself
23:10:37 dansmith I mean, just MHO, but.. seems more intuitive to me
23:11:10 gmann how about this 'functional-skip-sample-db-tests'
23:11:26 melwitt yeah maybe like functional-without-sample-tests-py38 or something
23:11:28 melwitt I agree, I think it would be more intuitive
23:11:42 dansmith cha
23:12:18 melwitt gmann: that sounds good, add -py38 at the end though right since it's 3.8 only?
23:12:19 gmann functional-without-sample-db-tests ? as it skip db test too and remove py38 thing as it can lengthy the name
23:12:25 melwitt oh
23:12:50 gmann melwitt: i was thinking just to run it on available py version as goal is not test py version in this job ?
23:13:14 gmann and we do not need to rename when we move to py39 or so
23:13:19 melwitt gmann: yeah true
23:13:31 melwitt yeah that makes sense
23:13:55 gmann ok, let me rename it.
23:14:07 melwitt k. will re +2 them after
23:14:14 gmann dansmith: melwitt do you think to move job definition also to nova side or it is ok?
23:15:40 melwitt gmann: I think the job def in placement is better, personally
23:16:09 gmann ok
23:23:35 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:43 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:25:04 gmann melwitt: dansmith ^^ updated
23:26:35 dansmith I didn't see a job def change
23:28:33 gmann dansmith: you mean for tox env rename or you were talking to change job name too ?
23:28:43 gmann https://review.opendev.org/c/openstack/placement/+/813680/2/.zuul.yaml
23:28:50 gmann dansmith: ^^
23:34:58 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:35:05 dansmith which it looks like is the case
23:35:29 gmann yeah.
23:35:39 gmann let's keep it there
23:35:55 dansmith doesn't the placement one need to depends-on the nova one?
23:37:20 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:43 gmann dansmith: yeah, it is depends-on
23:37:49 gmann melwitt: ^^ updated commit msg
23:38:03 dansmith sorry, I dunno what I was missing
23:38:36 dansmith gmann: sorry had the first patch open in two tabs I think
#openstack-nova - 2021-10-13
00:55:28 opendevreview Merged openstack/nova master: Define new functional test tox env for placement gate to run https://review.opendev.org/c/openstack/nova/+/813679
02:01:22 opendevreview Steve Baker proposed openstack/nova master: Remain in DELETING for ironic CLEANING, CLEANWAIT https://review.opendev.org/c/openstack/nova/+/813729
02:03:05 opendevreview Merged openstack/placement master: Use 'functional-without-sample-db-tests' tox env for placement nova job https://review.opendev.org/c/openstack/placement/+/813680
03:29:45 opendevreview melanie witt proposed openstack/nova master: Handle urlencoded lists when filtering servers by tags https://review.opendev.org/c/openstack/nova/+/813736
06:54:26 bauzas good morning Nova
06:55:03 gibi bauzas: o/
06:56:38 gibi gmann: thanks for unblocking the placement gate with https://review.opendev.org/c/openstack/placement/+/813680 I have concerns that we only solved the local problem and not the root of the problem in zuul. I do think that tox_extra_args is defined to pass extra args to tox, and the test case filter regexp is such extra args
06:57:31 gibi it is not even a problem that zuul passes that args to tox when printing the config as tox accepts the extra args there too, but the problem is that it is passed without proper quoting
06:57:56 gibi so whoever will use tox_extra_args for anything in zuul that needs quoting will hit the same issue as we hit
07:02:40 bauzas can't disagree with gibi here
07:02:52 bauzas but at least we unblocked the periodic run
07:03:24 gibi bauzas: yeah, I'm OK to unblock the gate then fix the real problem
07:03:28 gibi that is a good order
07:07:43 gibi bauzas: if you have time for a smallish workaround fix to review that would be appreciated https://review.opendev.org/c/openstack/nova/+/813419
07:08:14 bauzas gibi: sure, today I'm trying to dedicate time for upstream reviews and bug triage
07:08:53 gibi thanks
07:17:45 alecorps7 hello
07:38:23 bauzas gibi: -1 for a relnote missing but see my comments https://review.opendev.org/c/openstack/nova/+/813419
07:39:25 gibi bauzas: thanks, I will respin
07:39:36 gibi bauzas: regarding a better solution I discussed that with sean-k-mooney
07:39:56 gibi bauzas: we need more info from neutron to decide when to wait for a plug event from neutron
07:40:12 bauzas gibi: we can discuss this next week with the neutron folks
07:40:21 gibi bauzas: we can try yes
07:40:37 bauzas gibi: what I'd like is that *all* neutron backends should provide an event
07:40:56 bauzas nova shouldn't know which backend neutron uses
07:40:59 gibi bauzas: yes that would be also an option but I think that is a harder one
07:41:00 bauzas at least for an event
07:41:41 bauzas I don't understand why it'd be hard for neutron to provide an event for plugs
07:42:02 bauzas again, having events be different between neutron backends looks bad to me

Earlier   Later