Earlier  
Posted Nick Remark
#openstack-nova - 2025-01-06
14:30:45 sean-k-mooney well unless im on pto for a few weeks :)
16:21:34 opendevreview Takashi Kajinami proposed openstack/nova master: doc: Use dnf instead of yum https://review.opendev.org/c/openstack/nova/+/938496
16:24:07 opendevreview Takashi Kajinami proposed openstack/placement master: doc: Use dnf instead of yum https://review.opendev.org/c/openstack/placement/+/938499
17:31:54 dansmith artom: can you resolve the comments on your tpm spec that have been addressed? It's cluttered with lots of things, many of which seem out of date now
18:03:52 dansmith artom: left a bunch of comments that will make gibi hate me, let me know if you want to chat about them high-bandwidth
18:04:27 artom dansmith, lemme take a look
18:05:08 artom (I kinda assumed the original comment author would resolve their comment if my changes/response adequately addressed them. I always feel bad making others's stuff disappear)
18:07:38 sean-k-mooney artom: it depends, genneral expect the patch autor to mark them as done if they mad the change
18:07:51 sean-k-mooney but its kind fo a judgement call
18:10:41 dansmith yeah, which is why I hate the resolve stuff, but since it's there, someone has to do it
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 ?

Earlier   Later