| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-07 | |||
| 14:44:53 | dansmith | I'm pretty open today | |
| 14:45:43 | artom | The ACL vs make the Barbican secret owned by the Nova user thing is kind of a red herring, in the sense that it's an implementation detail that achieves the exact same thing (mostly): the Nova service user can read the Barbican secret. What we're really debating is - do we give access to the Nova user unconditionally, or do we make it opt-in for the user. | |
| 14:46:09 | artom | For the human user. | |
| 14:46:43 | sean-k-mooney | well there is that topci | |
| 14:46:59 | sean-k-mooney | but also shoudl we change how the vtpm secret is stored in libvirt so we can read it back | |
| 14:47:03 | dansmith | well, or if we use libvirt for it | |
| 14:47:04 | dansmith | yeah | |
| 14:47:24 | artom | That would make it a non-starter for rolling upgrades, so I thought we'd dropped that idea | |
| 14:47:24 | sean-k-mooney | and i think we shoudl check if libvirt can already copy it if its not marked as private for what its worth | |
| 14:47:38 | dansmith | and one thing we could discuss is how much of the implementation is the same (i.e. the copying of a secret from source, vs. the dest fetching it) on each thing | |
| 14:47:55 | dansmith | sean-k-mooney: I thought the spec said that wasn't implemented yet? | |
| 14:47:59 | sean-k-mooney | artom: im not conviced we shoudl be upgrading new vms to supprot this without requireing them to be cold migrated or hard rebooted or somethihng like that | |
| 14:48:15 | sean-k-mooney | dansmith: its definaly not supproted for private secrtes | |
| 14:48:39 | sean-k-mooney | but the docs for this is slightly odd so i would like to check what happens if we dont make them private | |
| 14:48:43 | artom | sean-k-mooney, OK, we definitely need a call then :P | |
| 14:48:54 | dansmith | artom: no, I'm not saying we should require the upgrade path, remember, I just said your reason didn't sound good enough to exclude it.. but if we exclude because of a better reason it's fine | |
| 14:49:04 | artom | Oh right. | |
| 14:49:42 | sean-k-mooney | fyi "The value of the secret must not be revealed to any caller of libvirt, nor to any other node." the bit after the comma makes me wonder what happens for non private secrets | |
| 14:50:14 | dansmith | sean-k-mooney: that sounds like it never tells anyone | |
| 14:50:28 | sean-k-mooney | correfct if its private | |
| 14:50:39 | sean-k-mooney | but the defualt is private=no | |
| 14:50:54 | sean-k-mooney | we epxlity mark only vtpm secreate as private=yes | |
| 14:51:58 | sean-k-mooney | i asked interanly on the virt channle late last night but no one responed | |
| 14:52:45 | sean-k-mooney | artom: how much work would it be for you to push up a DNM patch ot diabel the api block and test live migration with vtpm and jsut remove setting private=yes? | |
| 14:53:03 | sean-k-mooney | do you have a simialr patch already? | |
| 14:53:06 | artom | Not too much, I think? | |
| 14:53:26 | artom | I can piggy back off https://review.opendev.org/c/openstack/nova/+/925771 | |
| 14:54:09 | artom | Wait, no, I explicitly _don't_ want to piggy off that, because it has all the fetch-from-barbican-define-in-libvirt-on-the-dest mechanics | |
| 14:54:18 | sean-k-mooney | well you could jsut comment out https://review.opendev.org/c/openstack/nova/+/925771/6/nova/virt/libvirt/driver.py#11512 | |
| 14:54:27 | artom | And we want to test do-nothing-except-make-the-secret-public-and-see-if-it-magically-works | |
| 14:54:31 | sean-k-mooney | where you are adding the download | |
| 14:54:40 | sean-k-mooney | yes exactly | |
| 14:55:06 | sean-k-mooney | oh actully no there is one other change | |
| 14:55:21 | sean-k-mooney | you need to also stop nova deleteing the vtpm secrete after the vm boots | |
| 14:55:34 | gibi | dansmith: artom: sure I can jump on a call | |
| 14:55:40 | sean-k-mooney | so make it public and dont delete it | |
| 14:55:48 | gibi | I just finished with the SRIOV vGPU call | |
| 14:56:59 | dansmith | vkw-ozjo-pap | |
| 14:56:59 | dansmith | meet.google.com/vkw-ozjo-pap | |
| 14:57:29 | sean-k-mooney | im going to grab a drink but ill join shortly | |
| 14:58:00 | artom | Coming, just on a call to the mechanic where my car is | |
| 14:58:08 | artom | 1.5 hours away from Montreal :( | |
| 16:01:18 | bauzas | #startmeeting nova | |
| 16:01:18 | opendevmeet | Meeting started Tue Jan 7 16:01:18 2025 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:01:18 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:01:18 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:01:24 | bauzas | hi folks | |
| 16:01:29 | bauzas | who's around ? | |
| 16:01:34 | sean-k-mooney | o/ | |
| 16:01:40 | gibi | /o (partially) | |
| 16:01:56 | elodilles | o/ | |
| 16:02:17 | bauzas | (I'm partially here too but I need to run the meeting :) ) | |
| 16:03:14 | bauzas | okay let's start and hopefully it will be quick | |
| 16:03:57 | bauzas | #topic Bugs (stuck/critical) | |
| 16:04:02 | bauzas | #info No Critical bug | |
| 16:04:10 | bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | |
| 16:04:18 | bauzas | any bugs people wanna raise ? | |
| 16:04:21 | Uggla | o/ | |
| 16:04:57 | fwiesel | o/ | |
| 16:05:03 | bauzas | looks not, moving on | |
| 16:05:09 | bauzas | #topic Gate status | |
| 16:05:15 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | |
| 16:05:21 | bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | |
| 16:05:30 | bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status | |
| 16:05:52 | bauzas | nova-emulation is in the weeds | |
| 16:06:09 | bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |
| 16:06:15 | bauzas | #info Please try to provide meaningful comment when you recheck | |
| 16:07:51 | bauzas | #topic Release Planning | |
| 16:07:56 | bauzas | a few things to mention here | |
| 16:08:04 | bauzas | #link https://releases.openstack.org/epoxy/schedule.html | |
| 16:08:10 | bauzas | #info Nova deadlines are set in the above schedule | |
| 16:08:15 | bauzas | #info Implemention review day is planned tomorrow | |
| 16:08:32 | bauzas | I'll send an email about it ^ | |
| 16:08:58 | bauzas | #action bauzas to notify about review day thru email | |
| 16:09:13 | bauzas | the other, also important : | |
| 16:09:16 | bauzas | #info Specs approval freeze planned for Thursday EOB | |
| 16:09:22 | bauzas | you are warned | |
| 16:09:42 | bauzas | I'm mostly burned today by spec reviews and I'll continue tomorrow | |
| 16:09:58 | bauzas | anything worth mentioning now ? | |
| 16:10:26 | s3rj1k | late hey to all, connection issues | |
| 16:10:44 | bauzas | moving on | |
| 16:11:53 | bauzas | #topic Review priorities | |
| 16:12:01 | bauzas | #link https://etherpad.opendev.org/p/nova-2025.1-status | |
| 16:12:17 | bauzas | nothing to mention, continuing | |
| 16:12:23 | bauzas | #topic Stable Branches | |
| 16:12:32 | bauzas | elodilles: happy new year | |
| 16:12:36 | elodilles | :) | |
| 16:12:45 | elodilles | happy new year too o/ | |
| 16:12:46 | elodilles | :) | |
| 16:12:57 | elodilles | speaking of that | |
| 16:13:19 | elodilles | i see not much activity on stable branches in the past weeks | |
| 16:13:56 | elodilles | but i'm not aware of any stable gate issue | |
| 16:14:11 | elodilles | (maybe because of the above reason o:)) | |
| 16:14:27 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:14:49 | elodilles | please if you see any issue, add there ^^^ | |
| 16:15:09 | elodilles | that's all about stable branches from me | |
| 16:15:29 | bauzas | cool | |
| 16:15:47 | bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:16:04 | bauzas | fwiesel: heya, happy new year too | |
| 16:16:05 | fwiesel | Hi, happy new year. No updates from my side. | |