bauzas | elodilles: I did a couple of single-core approvals for the reno unmaintenained patches but please ping me if you find that I forgot some patch for other nova repos | 10:01 |
---|---|---|
frickler | bauzas: osc-placement is also nova team, isn't it? https://review.opendev.org/c/openstack/osc-placement/+/911294 etc. | 10:06 |
bauzas | that's correct, I'll do my duty then | 10:07 |
frickler | ty | 10:07 |
bauzas | I wish we could have some flag in gerrit query to say 'flag:nova-related' instead of 'project:<something> OR project:somethingelse> :) | 10:09 |
bauzas | I just don't know how other services that have like 50 repos do this :) | 10:09 |
opendevreview | Merged openstack/os-vif master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/os-vif/+/911292 | 10:12 |
opendevreview | Merged openstack/os-vif master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/os-vif/+/911282 | 10:12 |
opendevreview | Merged openstack/os-vif master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/os-vif/+/911272 | 10:12 |
elodilles | bauzas: ACK, thanks (i added review-priority+1 for them) | 10:12 |
opendevreview | Merged openstack/python-novaclient master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/python-novaclient/+/911288 | 10:12 |
opendevreview | Merged openstack/python-novaclient master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/python-novaclient/+/911278 | 10:12 |
opendevreview | Merged openstack/python-novaclient master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/python-novaclient/+/911298 | 10:12 |
bauzas | we gotta get a pile of them ^ :) | 10:13 |
elodilles | (well, sorry, i was talking about this ones: 'Update master for stable/2024.1') | 10:13 |
opendevreview | Merged openstack/osc-placement master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/osc-placement/+/911274 | 10:14 |
opendevreview | Merged openstack/osc-placement master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/osc-placement/+/911294 | 10:16 |
opendevreview | Merged openstack/osc-placement master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/osc-placement/+/911284 | 10:16 |
opendevreview | Merged openstack/nova master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/nova/+/911290 | 10:18 |
opendevreview | Sylvain Bauza proposed openstack/nova master: Update min support for Dalmatian https://review.opendev.org/c/openstack/nova/+/913890 | 10:19 |
opendevreview | Merged openstack/nova master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/nova/+/911270 | 10:22 |
opendevreview | Merged openstack/nova master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/nova/+/911280 | 10:24 |
sean-k-mooney[m] | bauzas: you can create a dashboard in gerrit | 12:23 |
bauzas | sure, I already use two of them | 12:24 |
bauzas | but OK, maybe I should create some dashboard for all the nova repos | 12:24 |
bauzas | (at least for the release bot ones :) | 12:25 |
bauzas | dansmith: gmann: I don't know what's the plan with grenade now we branched 2024.1 but I proposed https://review.opendev.org/c/openstack/grenade/+/913892 | 13:40 |
bauzas | oh, frickler gave me a procedural -2, cool | 13:40 |
opendevreview | Merged openstack/nova stable/2023.2: pwr mgmt: make API into a per-driver object https://review.opendev.org/c/openstack/nova/+/913196 | 13:43 |
sean-k-mooney | bauzas: that greneade patch looks correct to me | 13:45 |
sean-k-mooney | so ya once grenade is branched we shoudl be good | 13:45 |
bauzas | cool | 13:46 |
bauzas | dansmith: sean-k-mooney: while you're here, something procedural again about rolling-upgrades now we've branched 2024.1 : https://review.opendev.org/c/openstack/nova/+/913890 | 13:47 |
dansmith | needs a recheck? | 13:48 |
bauzas | because of multicell yeah | 13:48 |
bauzas | probably a guest kernel panic again, but haven't looked yet | 13:49 |
dansmith | ssh timeout | 13:49 |
bauzas | either way, grenade skip-level is happy so do I | 13:49 |
dansmith | no crash | 13:49 |
bauzas | (but skiplevels are actually setting the hack option, so meh) | 13:49 |
bauzas | dansmith: ack | 13:50 |
opendevreview | mike_mp@zzzcomputing.com proposed openstack/nova master: do not use str(url) to stringify a URL for subsequent use https://review.opendev.org/c/openstack/nova/+/913910 | 14:38 |
opendevreview | Merged openstack/nova stable/2023.2: Reproducer test for live migration with power management https://review.opendev.org/c/openstack/nova/+/913197 | 16:06 |
melwitt | sean-k-mooney: in case you missed it, I replied to your comment re: live migration with encryption a few days ago after I did some testing with cinder volume encryption https://review.opendev.org/c/openstack/nova/+/905512/21#message-23db60f810b5472343e21666c09292885b832a17 | 17:07 |
sean-k-mooney | i did ill read it now | 17:30 |
sean-k-mooney | ah so we do pull the key form barbican for cinder | 17:31 |
sean-k-mooney | melwitt: ill comment on the bug but ya we could copy the libvirt secret with either in the migration_data object or via ssh | 17:32 |
sean-k-mooney | im actully wonderign if we can tell libvirt to transfer the libivrt secret | 17:32 |
sean-k-mooney | i dont think it a teribly uncommon usecasue to have a domain and a secret related to that domain so i wonder if they have a native metond to copy such info | 17:33 |
sean-k-mooney | espically when in this case its a secret passed to qemu to decrypt the disks | 17:34 |
melwitt | I tend to think sending it over RPC wouldn't be good from a security perspective | 17:34 |
sean-k-mooney | i have been thinking about a solution for that for a diffent usecase but i agree unecypted it would be not good | 17:35 |
sean-k-mooney | i assumed that is why we dont do it today by the way | 17:35 |
melwitt | and I guess I also don't really see why we should not be able to require that barbican be available when live migrating. we expect all other services to be up (like keystone) | 17:37 |
sean-k-mooney | thats fair. the reans we need the other is we need to update there state to refect the move | 17:38 |
sean-k-mooney | we dont need to do that for barbaican swiift or glance | 17:38 |
sean-k-mooney | which keyston neutron cinder and placement yes | 17:39 |
sean-k-mooney | that a reasonable reason to pull form barbican i just was not expecting it | 17:39 |
melwitt | but keystone is "are you authorized to perform this action" and barbican is "are you allowed to access secrets for this encrypted server". should someone who isn't allowed to access the barbican secret for an encrypted server be able to move it? | 17:40 |
dansmith | maybe the answer to that is the admin should give themselves access to the secret in order to move it, | 17:43 |
dansmith | so it's in the audit log as such | 17:43 |
dansmith | and if they're an admin on nova and not barbican, then yeah maybe they shouldn't be able to move it | 17:44 |
melwitt | yeah, that's how it would work today | 17:44 |
sean-k-mooney | im fine with saying for now lets keep it consitent with the ux of encypted volumes | 17:49 |
sean-k-mooney | i think there is a better ux that we coudl deliver but i dont want to expand scope on this point | 17:49 |
melwitt | yeah, I was thinking if we want to do something different maybe that should be its own spec to change them both in the same manner | 17:50 |
sean-k-mooney | yep makes sense to me | 17:51 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!