| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-05-02 | |||
| 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? | |
| 16:40:18 | sean-k-mooney | dansmith: im not agaisn a min compute service version check in the api as well by the way | |
| 16:40:24 | bauzas | that's option 3 | |
| 16:40:25 | sean-k-mooney | i dont really think 2 is harsh | |
| 16:40:29 | bauzas | s/3/2 | |
| 16:40:46 | sean-k-mooney | we normally dont enabel feature untill the cloud is fully upgraded | |
| 16:40:54 | dansmith | I'm not saying that's how it needs to be, I'm just saying it feels like we're bordering on trait abuse here | |
| 16:40:56 | dansmith | so FWIW, | |
| 16:41:10 | sean-k-mooney | we have in the past done this on a per compute host bassis | |
| 16:41:15 | dansmith | we could also have a scheduler filter that requires a service version at or above a number | |
| 16:41:20 | sean-k-mooney | but in generall i think a min comptue version check is preferable | |
| 16:41:23 | dansmith | and we could add hints/advice to the scheduler for this sort of thing | |
| 16:41:31 | dansmith | which would be nice for this and other things I imagine | |
| 16:41:49 | bauzas | yeah this sounds quite a reasonable tradeoff | |
| 16:42:03 | sean-k-mooney | this being? | |
| 16:42:20 | bauzas | I'm just wondering whether we expose the service version on the scheduling side | |
| 16:42:31 | sean-k-mooney | i think you can already schedul based on the comptue service version | |
| 16:42:45 | sean-k-mooney | with either the json of comptue capablity filter | |
| 16:42:58 | sean-k-mooney | but in any case we want this to work without any configuration requried | |
| 16:43:20 | sean-k-mooney | bauzas: why not just do 2? | |
| 16:43:24 | gibi | I might miss something but if this feature nees compute code + libirt/qemu version then as simple compute version check is not enough | |