| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-05-02 | |||
| 16:13:53 | bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures | |
| 16:14:04 | bauzas | there it is time to discuss gate failures now | |
| 16:14:26 | bauzas | dansmith: shoot the good news and the bad ones if you have | |
| 16:14:49 | dansmith | tldr is that I have got the ceph job moved to jammy and cephadm and it's working finally, and: | |
| 16:15:10 | dansmith | that I found a bunch of places where we thought we were requiring SSHABLE before volume activities where it was being silently ignored | |
| 16:15:17 | dansmith | basically what gibi asserted | |
| 16:15:28 | dansmith | so I've got a stack of tempest patches (and cinder-tempest-plugin) to not only fix those, | |
| 16:15:51 | dansmith | but also sanity check and raise an error if someone asks for SSHABLE but without the requisite extra stuff to actually honor it | |
| 16:16:13 | dansmith | that helps us pass the ceph job in the new config but will also likely help improve volume failures in the other jobs | |
| 16:16:37 | bauzas | cool | |
| 16:16:43 | bauzas | thanks for the janitorisation | |
| 16:16:57 | gibi | dansmith: awesome | |
| 16:17:06 | gibi | thank you | |
| 16:17:16 | bauzas | which patches shall be looked at for people who care ? | |
| 16:17:24 | dansmith | it's been a lot of work and frustration, but happy to see it becoming fruitful | |
| 16:17:36 | dansmith | well, no patches to nova, but I can get you a link, hang on | |
| 16:17:56 | gmann | this one #link https://review.opendev.org/q/topic:sshable-volume-tests | |
| 16:18:00 | dansmith | this stack on tempest: https://review.opendev.org/c/openstack/tempest/+/881925 | |
| 16:18:14 | dansmith | and this one against cinder-tempest https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/881764 | |
| 16:18:30 | dansmith | the nova patch I have up is a DNM just to test our job with that full stack, but we don't need to merge anything | |
| 16:18:55 | bauzas | #link https://review.opendev.org/q/topic:sshable-volume-tests Tempest patches that add more ssh checks for volume-related tests | |
| 16:19:11 | bauzas | cool excellent, thanks a lot dansmith for this hard work | |
| 16:19:32 | bauzas | that's noted. | |
| 16:19:50 | bauzas | any other CI failure to relate or mention ? | |
| 16:20:22 | bauzas | looks not, excellent | |
| 16:20:37 | bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | |
| 16:21:08 | bauzas | the fips job run had a node failure, but should be green next week | |
| 16:22:11 | bauzas | on a side note, I'm trying to add some kind of specific vgpu job that would use the mtty sample framework for validating the usage we have on a periodic basis | |
| 16:22:55 | bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |
| 16:23:01 | bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | |
| 16:23:06 | bauzas | that's it for me on that topic | |
| 16:23:08 | bauzas | moving on | |
| 16:23:15 | bauzas | #topic Release Planning | |
| 16:23:19 | bauzas | #link https://releases.openstack.org/bobcat/schedule.html | |
| 16:23:31 | bauzas | #info Nova deadlines are set in the above schedule | |
| 16:23:37 | bauzas | #info Bobcat-1 is in 1 weeks | |
| 16:23:56 | bauzas | #info Next Tuesday 9th is stable branches review day https://releases.openstack.org/bobcat/schedule.html#b-nova-stable-review-day | |
| 16:24:24 | bauzas | I'll communicate on that review day by emailing -discuss | |
| 16:24:46 | bauzas | but let's discuss that more in the stable topic we have later | |
| 16:25:04 | bauzas | #topic Review priorities | |
| 16:25:04 | bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2) | |
| 16:25:06 | bauzas | #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review | |
| 16:25:11 | bauzas | #topic Stable Branches | |
| 16:25:16 | bauzas | elodilles: go for it | |
| 16:25:23 | elodilles | #info stable nova versions were released for zed (26.1.1) and for yoga (25.1.1) last week | |
| 16:25:29 | elodilles | otherwise not much happened | |
| 16:25:35 | bauzas | rigt | |
| 16:25:38 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:25:50 | elodilles | that's all from me | |
| 16:27:05 | bauzas | excellent thanks | |
| 16:27:30 | bauzas | and as I said just before, we shall round about some patches next week hopefully | |
| 16:27:36 | elodilles | \o/ | |
| 16:28:02 | bauzas | #topic Open discussion | |
| 16:28:11 | bauzas | (enriquetaso) Discuss the blueprint: NFS Encryption Support for qemu | |
| 16:28:14 | bauzas | enriquetaso: shoot | |
| 16:28:18 | enriquetaso | hi | |
| 16:28:21 | enriquetaso | sure | |
| 16:28:30 | enriquetaso | As discussed on the PTG a couple weeks ago. I’ve proposed the blueprint. | |
| 16:28:30 | enriquetaso | As discussed on the PTG a couple weeks ago. I’ve proposed the blueprint. | |
| 16:28:42 | enriquetaso | #link https://blueprints.launchpad.net/nova/+spec/nfs-encryption-support | |
| 16:28:57 | enriquetaso | Summary: Cinder is working on supporting encryption on NFS volumes. To do this NFS driver uses LUKS inside qcow2 for this. | |
| 16:29:10 | enriquetaso | This affects Nova because Nova cannot handle qemu + LUKS inside qcow2 disk format at the moment. | |
| 16:29:25 | enriquetaso | What are your thoughts? | |
| 16:29:35 | enriquetaso | should I mention the rolling upgrades would be a problem on the bp ? | |
| 16:30:20 | bauzas | lemme reopen the ptg notes | |
| 16:30:50 | bauzas | right | |
| 16:31:51 | bauzas | we basically said we were quite okay with the proposed design but we were wondering if it was worth not scheduling to old computes | |
| 16:32:03 | bauzas | we have three options here : | |
| 16:32:23 | bauzas | 1/ avoid scheduling to old computes (by adding a prefilter) | |
| 16:33:07 | bauzas | 2/ preventing this feature on the API level by checking the compute service versions | |
| 16:33:59 | bauzas | 3/ do some compute check that would prevent the volume to be encryped on some preconditionsq | |
| 16:34:36 | bauzas | #2 seems a bit harsh to me | |
| 16:35:02 | sean-k-mooney | dind we discusss addign a trait | |
| 16:35:07 | bauzas | we did it | |
| 16:35:09 | sean-k-mooney | so 1 | |
| 16:35:21 | bauzas | without having full quorum, hence me restating the options | |
| 16:35:34 | sean-k-mooney | well i vote 1 or file a spec | |
| 16:36:04 | bauzas | then I tend to say option #1 and specless blueprint as we basically went down | |
| 16:36:12 | gibi | I'm OK with 1/ | |
| 16:36:16 | sean-k-mooney | becasue if we dont just use a trait/prefileter then i think we need a spec to expalin why that is not sufficent and descirbe it in detail | |
| 16:37:01 | dansmith | so a trait of "this is newer than X"? | |
| 16:37:09 | sean-k-mooney | no | |
| 16:37:16 | dansmith | that's kinda fundamentally wrong, so you need to expose it as a feature flag | |
| 16:37:22 | sean-k-mooney | COMPUTE_somehting | |
| 16:37:36 | bauzas | sean-k-mooney: do we all agree now that we accept a new trait saying something like "I_CAN_ENCRYPT_YOUR-STUFF" | |
| 16:37:38 | dansmith | is there any compute config that needs to be enabled? if so, ideally that would control the exposure (or not) of the trait | |
| 16:37:38 | sean-k-mooney | to report the hypervers capablity to supprot lux in qcow | |
| 16:37:56 | sean-k-mooney | dansmith: i think this just need to check the qemu/libvirt version | |
| 16:38:00 | bauzas | my only concern is the traits inflation but that's a string | |
| 16:38:02 | sean-k-mooney | and report it statically if we are above that | |
| 16:38:09 | sean-k-mooney | i dont think we need a cofnig option | |
| 16:38:17 | bauzas | sean-k-mooney: that's why I was considering option 3 | |
| 16:38:35 | dansmith | sean-k-mooney: yeah, that's just a little annoying I think | |
| 16:38:39 | bauzas | which would be "meh dude, you don't have what I need, I'll just do what I can do" | |
| 16:38:45 | sean-k-mooney | bauzas: i dont think optional encypting is accpetable | |
| 16:38:47 | dansmith | because it becomes not as much a feature flag but a shadow version number | |
| 16:39:22 | bauzas | sean-k-mooney: true | |
| 16:39:28 | sean-k-mooney | if you asked for the storage to be enypeed we either need to do it or raise an error | |
| 16:40:05 | bauzas | sounds then reasonable to ERROR the instance | |
| 16:40:12 | enriquetaso | what a `new trait` involves? | |