| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-16 | |||
| 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? | |
| 11:21:48 | sean-k-mooney | it lest you know if it will fail but no need to recheck it | |
| 11:59:15 | admin1 | where is the live_migration_downtime defined ? | |
| 11:59:19 | admin1 | is it on kvm or in nova ? | |
| 12:01:15 | sean-k-mooney | admin1: nova has options that we pass to libvirt which then modulates the qemu downtime | |
| 12:01:37 | sean-k-mooney | admin1: https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_downtime | |
| 12:01:56 | sean-k-mooney | admin1: nova is not direcly involved in managing the vm during the livemigration | |
| 12:02:15 | sean-k-mooney | we invoke libvirt wiht a set of parmaters and then wait for ti to complete | |
| 12:04:38 | sean-k-mooney | melwitt: i think this is all you need to fix in the backports for bionic by the way https://review.opendev.org/c/openstack/nova/+/795433/1/roles/run-evacuate-hook/tasks/main.yaml#44 | |
| 12:05:12 | sean-k-mooney | well and lines 67-69 | |
| 12:05:53 | sean-k-mooney | the version of libvirt in bionic does not support socket activation so we just need to remove the socket lines | |
| 12:11:22 | admin1 | sean-k-mooney, so i just need to add those lines in nova.conf, restart the compute service ( systemctl ) and thats it ? | |
| 12:11:51 | admin1 | are those lines only needed in the actual compute nodes, or in the whole cluster ( nova scheduler, api etc ) ? | |
| 12:12:34 | sean-k-mooney | they are used on the source compute i think | |