Earlier  
Posted Nick Remark
#openstack-nova - 2025-01-06
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 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:24 artom That would make it a non-starter for rolling upgrades, so I thought we'd dropped that idea
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 meet.google.com/vkw-ozjo-pap
14:56:59 dansmith 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 opendevmeet The meeting name has been set to 'nova'
16:01:18 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
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 bauzas #startmeeting 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/

Earlier   Later