Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-06-16
08:57:57 gibi i.e. not to fail on if the change already applied
08:58:19 gibi I have to run now but we can talk about it later
08:58:36 stephenfin okay, no worries. We'll just have to document it, I suppose
09:12:55 opendevreview Stephen Finucane proposed openstack/nova master: db: Remove dead code https://review.opendev.org/c/openstack/nova/+/786291
09:12:56 opendevreview Stephen Finucane proposed openstack/nova master: db: Remove 'nova.db.sqlalchemy.utils' https://review.opendev.org/c/openstack/nova/+/786292
09:12:57 opendevreview Stephen Finucane proposed openstack/nova master: db: Remove unused DB methods https://review.opendev.org/c/openstack/nova/+/786293
09:12:57 opendevreview Stephen Finucane proposed openstack/nova master: db: Use module-level imports for sqlalchemy https://review.opendev.org/c/openstack/nova/+/786295
09:12:58 opendevreview Stephen Finucane proposed openstack/nova master: db: Fold in indexes https://review.opendev.org/c/openstack/nova/+/786296
09:12:59 opendevreview Stephen Finucane proposed openstack/nova master: db: Fold in ForeignKey constraints https://review.opendev.org/c/openstack/nova/+/786297
09:13:00 opendevreview Stephen Finucane proposed openstack/nova master: db: Remove 'nova.db.base' module https://review.opendev.org/c/openstack/nova/+/786298
09:13:01 opendevreview Stephen Finucane proposed openstack/nova master: db: Copy docs from 'nova.db.*' to 'nova.db.sqlalchemy.*' https://review.opendev.org/c/openstack/nova/+/786299
09:13:02 opendevreview Stephen Finucane proposed openstack/nova master: db: Synchronize function signatures https://review.opendev.org/c/openstack/nova/+/786300
09:13:02 opendevreview Stephen Finucane proposed openstack/nova master: db: Clean up migration code https://review.opendev.org/c/openstack/nova/+/786301
09:13:03 opendevreview Stephen Finucane proposed openstack/nova master: db: Use module-level imports for sqlalchemy (for real) https://review.opendev.org/c/openstack/nova/+/796519
09:19:04 opendevreview Lee Yarwood proposed openstack/nova stable/victoria: libvirt: Set driver_iommu when attaching virtio devices to SEV instance https://review.opendev.org/c/openstack/nova/+/796611
09:44:39 opendevreview Lee Yarwood proposed openstack/nova stable/ussuri: libvirt: Set driver_iommu when attaching virtio devices to SEV instance https://review.opendev.org/c/openstack/nova/+/796618
09:49:01 kashyap sean-k-mooney[m]: Hey, remind me again: do you think we can set a different display device based on guest's capabilities? E.g. if the guest has a virtio-gpu driver, use "virtio-vga" and so on
10:06:43 stephenfin lyarwood, gibi: bauzas is out for all of this week, right? Could I ask you to work through that DB series before it goes into merge conflict again. It's very trivial, if that helps (mostly moving things around in prep for alembic)
10:06:57 bauzas no, I'm here
10:07:02 alex_xu gibi: I reviewed few around on first three patches, since the major logic on the the thrid one.
10:07:20 bauzas I was just having a conflict for the upstream meeting
10:07:40 stephenfin bauzas: oh, sorry /o\ in that case, I might ask you to take a look also, if you can :)
10:07:59 bauzas stephenfin: yup, I can do it
10:08:05 stephenfin great, ty
10:10:08 stephenfin elodilles_afk: lyarwood: melwitt: Now that we have the cherry-pick check to prevent us backporting a change out-of-order, would it make sense to start approving a whole series of backports at once and relying on said check to prevent out-of-order merges?
10:29:04 lyarwood stephenfin: sorry was on a call, happy to help with the DB series. We can but until the parent branch changes have landed the SHAs can still change but I guess that's the case either way. I'd be happy justifying +W'ing something if the parent is already W'd tbh.
10:29:33 stephenfin doesn't the cherry-pick script take care of that?
10:29:37 stephenfin the SHAs
10:29:51 lyarwood Yeah checking them, it doesn't automatically update anything
10:30:12 lyarwood I was agreeing that we may as well ACK things all the way down and rely on the script
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 bauzas stephenfin: ah that
10:33:05 stephenfin ah yeah, there's going to be a recheck anyway
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

Earlier   Later