| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-06 | |||
| 18:22:31 | dansmith | sean-k-mooney: iso+gpt now passing: https://review.opendev.org/c/openstack/nova/+/931833 | |
| 18:33:10 | sean-k-mooney | awsome | |
| 18:48:05 | artom | dansmith, left some answers. I fixed all the typos, but I won't push just yet with no other changes so far, pending more discussion. | |
| 19:04:39 | artom | dansmith, I think I'm coming around to your way of thinking - re: making the secrets owned by the Nova user, if that only means that compute host root and no one else gets access to them. | |
| 19:05:22 | artom | Out of respect for gibi, I'd like to get his thoughts when he's back | |
| 19:05:26 | dansmith | either that or libvirt storing them seems like the ideals you're going for.. not exposing to the api admin person, but allowing the system to reboot and migrate instances on their behalf if authorized to do so | |
| 19:05:39 | dansmith | the benefit of the former means they're not stored on disk if in the theft case | |
| 19:05:47 | dansmith | artom: for sure, wait for gibi of course | |
| 19:06:03 | artom | Storing in libvirt would break your rolling upgrades live migration point. | |
| 19:06:19 | artom | If the source isn't using the new code, it can't read it back and send it to the new dest. | |
| 19:06:34 | dansmith | yep | |
| 19:06:47 | artom | So we're converging on making it Nova-owned. | |
| 19:07:01 | dansmith | I wasn't making the argument for that being mandatory, I was saying that your argument for why it's not in your arrangement seemed weak | |
| 19:07:14 | dansmith | if there's a stronger technical reason for it, then it's reasonable | |
| 19:07:53 | artom | Ack. | |
| 19:08:08 | artom | So - do I want to rewrite this now, or chat to gibi first? | |
| 19:08:18 | dansmith | nah, wait for gibi | |
| 19:08:53 | artom | *procrastinating artom is happy* | |
| 19:41:15 | sean-k-mooney | dansmith: artom: i was try8ing to figure out why downstream ci was failing an gave up so i was not following ^ | |
| 19:41:32 | artom | sean-k-mooney, don't bother, it's an infra thing | |
| 19:41:37 | sean-k-mooney | but skiming back dansmith are you in favor fo the tpm secret beign owned by nova | |
| 19:41:43 | artom | sean-k-mooney, you can just read the comments on the review | |
| 19:41:49 | artom | sean-k-mooney, tl;dr yes that you just said | |
| 20:36:34 | opendevreview | Merged openstack/nova master: Refactor response schemas for share API https://review.opendev.org/c/openstack/nova/+/936656 | |
| 21:25:52 | opendevreview | sean mooney proposed openstack/nova master: [WIP] allow discover host to be enabeld in multiple schedulers https://review.opendev.org/c/openstack/nova/+/938523 | |
| 21:37:59 | opendevreview | sean mooney proposed openstack/nova master: [WIP] allow discover host to be enabeld in multiple schedulers https://review.opendev.org/c/openstack/nova/+/938523 | |
| #openstack-nova - 2025-01-07 | |||
| 01:39:41 | opendevreview | Takashi Kajinami proposed openstack/nova master: doc: Use dnf instead of yum https://review.opendev.org/c/openstack/nova/+/938496 | |
| 11:21:18 | opendevreview | huanhongda proposed openstack/nova master: Rollback live migration when virt driver failed https://review.opendev.org/c/openstack/nova/+/938154 | |
| 14:43:37 | dansmith | artom: gibi sean-k-mooney melwitt do you want to jump on a high-bandwidth chat today about the tpm stuff? | |
| 14:44:20 | artom | Was just about to say... | |
| 14:44:33 | sean-k-mooney | am sure i can whenever | |
| 14:44:45 | sean-k-mooney | im almost doen my first pass on the vfio-variant driver spec | |
| 14:44:49 | sean-k-mooney | (the first one) | |
| 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 | |