Posted	Nick	Remark
#openstack-nova - 2021-06-16
10:30:21	stephenfin	ah, okay, yeah, that's my thinking
10:30:34	bauzas	in general, we prefer to hold stable changes until master merges
10:30:42	bauzas	as indeed SHA1s can change
10:30:45	lyarwood	right stephenfin's point is after that on stable
10:30:53	stephenfin	oh, I'm not arguing for approving before master is merged
10:30:55	lyarwood	instead of waiting for each branch to merge
10:30:58	stephenfin	we should definitely wait for that
10:31:10	lyarwood	there is a potential race at that point stephenfin
10:31:19	lyarwood	the older branches having less CI
10:31:20	bauzas	stephenfin: sorry if i misunderstood, your concern is about a series ?
10:31:24	lyarwood	will fail first
10:31:38	lyarwood	because the newer branches haven't merged the required change
10:32:30	stephenfin	bauzas: I'm suggesting if you have a patch backported from stable/wallaby to stable/train, we can approve all of them at once and rely on the pep8 job to ensure they go in in the correct order
10:32:34	opendevreview	Sylvain Bauza proposed openstack/nova-specs master: Add generic mdevs to Nova https://review.opendev.org/c/openstack/nova-specs/+/792796
10:32:54	lyarwood	I'm fine with it, it's just going to take a few rechecks still
10:33:05	stephenfin	ah yeah, there's going to be a recheck anyway
10:33:05	bauzas	stephenfin: ah that
10:33:19	lyarwood	what's life without 20 rechecks
10:33:20	stephenfin	since the pep8 job will fail on everything older than stable/wallaby
10:33:23	lyarwood	yup
10:33:30	bauzas	well, in general, I'm holding approvals until the original branch merges
10:33:48	stephenfin	but it's easy to recheck one by one
10:33:50	bauzas	as they can be races
10:33:55	bauzas	there*
10:34:15	stephenfin	certainly easier than asking stable cores every few days to review the latest stable branch
10:34:56	stephenfin	bauzas: again, no issues holding off on approving (or even reviewing) backports until the master change has landed
10:35:19	stephenfin	but the pep8 job means that e.g. a stable/train change simply can't land before the stable/ussuri one now
10:35:23	stephenfin	even if +Wd
10:35:29	bauzas	oh, I see your point
10:35:38	bauzas	well, then sure
10:36:44	stephenfin	I just want to avoid having to continuously poll stable cores as each stable branch lands, particularly since I'm typically going back to Train (so that's four instances of polling, at a minimum :))
10:36:59	lyarwood	the only issue I have personally is that it breaks my review dashboards
10:37:13	lyarwood	as they rely on reviews being +1'd
10:37:35	lyarwood	but I guess someone is asking us to review a given topic here making it easier
10:37:41	lyarwood	and/or change-id
10:38:20	stephenfin	yeah, I'd like it if we could use something other than the verified label for this
10:39:51	stephenfin	like a Parent-Merged label, without which zuul wouldn't merge the patch (so like Verified in that way). I don't know how hard that is though. I don't know if a zuul job can set a label other than verified
10:40:40	stephenfin	however, as things stand, the dashboard is already broken so nothing has changed, right lyarwood?
10:40:52	stephenfin	because of the pep8 fail
10:41:05	lyarwood	yeah correct things are hidden
10:41:45	lyarwood	tinyurl.com/f9y6vr6d for example
10:42:11	lyarwood	tbh I could just change them to drop the +1 requirement
10:42:16	lyarwood	but then it gets a little mad
10:42:49	stephenfin	I can imagine
10:43:07	lyarwood	I still use https://review.opendev.org/q/project:openstack/nova+branch:%5Estable/.*+status:open from time to time to check everything
10:44:13	stephenfin	oh, zuul itself
10:44:19	stephenfin	https://opendev.org/zuul/zuul/src/branch/master/doc/source/examples/pipelines/gerrit-reference-pipelines.yaml
10:44:30	stephenfin	so we'd need a new pipeline
10:44:37	lyarwood	it would be nice to have something else the script could set tbh
10:45:51	stephenfin	the other option is to have a separate "CI" running that particular job, so you could filter on that instead
10:46:01	stephenfin	i.e. -1 by $PEP8_CI
10:46:19	stephenfin	again, no idea how difficult that is. I suspect that name is global to the deployment
10:48:26	stephenfin	oh, we could just move it to a separate job in the gate queue?
10:48:34	stephenfin	instead of the check queue
10:51:32	lyarwood	yeah I'm cool with that
10:51:55	lyarwood	well it would have to be non-voting, slightly defeating the purpose of the script
10:52:57	stephenfin	would it? The check job would now report +1 but the gate job would -2 if the parent wasn't merged
10:53:29	lyarwood	Ah sorry I see what you're suggesting now
10:53:37	lyarwood	Okay yeah that could work well in that case
11:04:49	opendevreview	Stephen Finucane proposed openstack/nova master: Move 'check-cherry-picks' test to gate https://review.opendev.org/c/openstack/nova/+/796626
11:04:53	stephenfin	lyarwood: ^
11:05:01	sean-k-mooney	kashyap: no we cant know the guest capablites in advance
11:06:34	kashyap	sean-k-mooney: Hmm, okay; I have a couple more questions. But I'm on a call, will come back to them in a bit.
11:06:42	sean-k-mooney	kashyap: the closest thing w have to that is libosinfo but that is not a greate approch in my view
11:06:54	sean-k-mooney	ack
11:07:19	kashyap	Right; 'libosinfo' was what I was thinking; why isn't it feasible? Do outline your thoughts here; will come back and read
11:09:15	sean-k-mooney	we have libosinfo "support" today but its not machine type aware and it does not know if you have the driver avaiable
11:09:29	sean-k-mooney	they also can change the hardware modeles over time which has broken us in the past
11:09:44	sean-k-mooney	and it currently missues the image propety fields
11:10:04	sean-k-mooney	it forches you to put the version in the os name field ignoring the os_version field
11:10:26	sean-k-mooney	so have to do os_name rhel8 not os_name rhel os_version 8
11:10:41	sean-k-mooney	so it breaks the standard usage of that attribute
11:11:16	sean-k-mooney	the lib osinfo devs assume that the xml will be persisted so its ok for them to break compatiablity and change the resules in later versions
11:11:24	sean-k-mooney	that is not how openstack works
11:12:20	sean-k-mooney	libosinfo also has no awareness of the libvirt verison installed on the system as far as i am aware so it does not know if the models are supported by the libvirt/qemu installed
11:12:38	lyarwood	stephenfin: LGTM
11:12:43	sean-k-mooney	this is why i recommend that no one ever use this feature and why i have suggested removing it in the past
11:14:49	lyarwood	stephenfin: wait, the `deps =` line in the tox env isn't a mistake is it?
11:16:35	sean-k-mooney	lyarwood: i belive that ill install no deps
11:16:46	sean-k-mooney	which in this case is fine
11:16:50	sean-k-mooney	we just need bash
11:17:03	lyarwood	yeah wasn't sure if tox would bork at it tis all
11:17:14	sean-k-mooney	well the ci will tell us
11:18:20	sean-k-mooney	lyarwood: stephenfin why are we doing this by the way
11:18:47	sean-k-mooney	i agree we can do this but i dont expect this to really save much time in the gate
11:19:13	lyarwood	sean-k-mooney: it should save at least one check run per backport
11:19:26	lyarwood	sean-k-mooney: but really this is more about allowing stable cores to see acceptable backports earlier
11:19:44	lyarwood	sean-k-mooney: so instead of them getting -1'd by the cherry pick script they just get held by the gate
11:19:49	sean-k-mooney	ya so reading the commit message im not sure i buy that
11:20:00	sean-k-mooney	but the 1 recheck i guess makes sense
11:20:23	sean-k-mooney	althoguh we are loosing one thing that would be nice to keep
11:20:40	sean-k-mooney	which is check that backports to stable acutlly are a backport or have stable only
11:20:54	lyarwood	we still get that, it's just in the gate now
11:21:02	sean-k-mooney	yep which is too late
11:21:11	lyarwood	tbh we could make this non voting in the check queue
11:21:17	sean-k-mooney	it should tell author that are unfamilar with our policy in check
11:21:27	sean-k-mooney	this new job
11:21:30	sean-k-mooney	that would work for me
11:21:31	lyarwood	yeah
11:21:44	lyarwood	stephenfin: ^ is that okay?

Earlier   Later