Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-10-12
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
07:44:40 bauzas gibi: just added a point about this in https://etherpad.opendev.org/p/nova-yoga-ptg L105
07:49:10 gibi bauzas: thanks I will try to fill in the details htere
07:49:12 gibi sean-k-mooney: ^^
07:49:13 gibi fy
07:49:15 gibi fyi
08:42:58 frickler bauzas: lots of jobs with POST_FAILURE for failing log upload, but they seem to be back now, so safe to recheck hopefully
08:44:16 bauzas frickler: yeah the outage is now done
08:44:40 bauzas they isolated the faulty DC
08:45:19 bauzas thread in French https://twitter.com/olesovhcom/status/1448196879020433409
08:47:55 opendevreview Elod Illes proposed openstack/nova stable/ussuri: Revert "[stable-only] Set lower-constraints job as non-voting" https://review.opendev.org/c/openstack/nova/+/813784
09:45:52 sean-k-mooney bauzas: nova really really really need to know what what backend neutron uses
09:46:17 sean-k-mooney bauzas: or they need to tell use exactly when they will send the envents for that backend opacly
09:47:01 sean-k-mooney bauzas: not all backend can send plug time events because they dont all have a way to send info too neutron about when the port is created and its finsihed wiring it up
09:47:24 sean-k-mooney bauzas: at present ovn cannot do that although the ml2 dirver can be modifed to eventually do that
09:48:04 sean-k-mooney bauzas: for odl they had to create a websocket on the netorn server and modify odl to seend events to that websocket to implemente plug time events whihc invovled a lot fo code development in odl
09:48:41 sean-k-mooney bauzas: contrail still has not implemnted multiple port binding gettingthem to send plug time events likely will never happen
09:49:27 sean-k-mooney linux bridge can send pulg time event but because it currently pool for interface chcnages insted of opening a netlink socket and reciving event it can miss the removal and addtion of interface on hard reboot
09:50:40 bauzas sean-k-mooney: sorry but for me, events are like notifications
09:50:49 bauzas sean-k-mooney: it's kinda a public API
09:51:23 sean-k-mooney bauzas: its more a contract
09:52:16 sean-k-mooney bauzas: i proposed that neutron tell use when they send events or normalise to a common contract back in train and neutron did not agree to either
09:52:49 opendevreview Alexey Stupnikov proposed openstack/nova master: Rollback problematic port bindings on source host only https://review.opendev.org/c/openstack/nova/+/813659
09:55:34 sean-k-mooney bauzas: you can see in the first version fo thsi we had a network_events section https://review.opendev.org/c/openstack/neutron-specs/+/645173/1/specs/train/port-binding-extended-information.rst#141
09:58:40 sean-k-mooney bauzas: this is the orginal etherpad i wrote with rodolfo https://etherpad.opendev.org/p/portbinding-records
09:59:38 sean-k-mooney it was coverd durign the train corss project session https://etherpad.opendev.org/p/ptg-train-xproj-nova-neutron
10:00:47 sean-k-mooney bauzas: i am fine with finding a better solution to what i proposed in thte past however nova must know the behaivor of the neutron backend to operat correctly
10:01:39 sean-k-mooney what we are doing today is complex and very error prone and i spend far too much of my time currently fixing bugs that are cause by not knowing when events will be sent

Earlier   Later