| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-03-20 | |||
| 21:50:56 | sean-k-mooney | sure | |
| 21:51:01 | melwitt | sean-k-mooney: ack, ok | |
| #openstack-nova - 2024-03-21 | |||
| 10:01:34 | 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:06:38 | frickler | bauzas: osc-placement is also nova team, isn't it? https://review.opendev.org/c/openstack/osc-placement/+/911294 etc. | |
| 10:07:00 | bauzas | that's correct, I'll do my duty then | |
| 10:07:56 | frickler | ty | |
| 10:09:11 | 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:35 | bauzas | I just don't know how other services that have like 50 repos do this :) | |
| 10:12:03 | opendevreview | Merged openstack/os-vif master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/os-vif/+/911292 | |
| 10:12:04 | opendevreview | Merged openstack/os-vif master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/os-vif/+/911282 | |
| 10:12:05 | opendevreview | Merged openstack/os-vif master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/os-vif/+/911272 | |
| 10:12:36 | elodilles | bauzas: ACK, thanks (i added review-priority+1 for them) | |
| 10:12:44 | opendevreview | Merged openstack/python-novaclient master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/python-novaclient/+/911288 | |
| 10:12:46 | opendevreview | Merged openstack/python-novaclient master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/python-novaclient/+/911278 | |
| 10:12:47 | opendevreview | Merged openstack/python-novaclient master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/python-novaclient/+/911298 | |
| 10:13:05 | bauzas | we gotta get a pile of them ^ :) | |
| 10:13:52 | elodilles | (well, sorry, i was talking about this ones: 'Update master for stable/2024.1') | |
| 10:14:28 | opendevreview | Merged openstack/osc-placement master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/osc-placement/+/911274 | |
| 10:16:54 | opendevreview | Merged openstack/osc-placement master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/osc-placement/+/911294 | |
| 10:16:55 | opendevreview | Merged openstack/osc-placement master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/osc-placement/+/911284 | |
| 10:18:57 | opendevreview | Merged openstack/nova master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/nova/+/911290 | |
| 10:19:04 | opendevreview | Sylvain Bauza proposed openstack/nova master: Update min support for Dalmatian https://review.opendev.org/c/openstack/nova/+/913890 | |
| 10:22:27 | opendevreview | Merged openstack/nova master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/nova/+/911270 | |
| 10:24:27 | opendevreview | Merged openstack/nova master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/nova/+/911280 | |
| 12:23:42 | sean-k-mooney[m] | bauzas: you can create a dashboard in gerrit | |
| 12:24:15 | bauzas | sure, I already use two of them | |
| 12:24:47 | bauzas | but OK, maybe I should create some dashboard for all the nova repos | |
| 12:25:12 | bauzas | (at least for the release bot ones :) | |
| 13:40:15 | 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:29 | bauzas | oh, frickler gave me a procedural -2, cool | |
| 13:43:53 | 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:45:19 | sean-k-mooney | bauzas: that greneade patch looks correct to me | |
| 13:45:42 | sean-k-mooney | so ya once grenade is branched we shoudl be good | |
| 13:46:38 | bauzas | cool | |
| 13:47:20 | 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:48:14 | dansmith | needs a recheck? | |
| 13:48:53 | bauzas | because of multicell yeah | |
| 13:49:13 | bauzas | probably a guest kernel panic again, but haven't looked yet | |
| 13:49:30 | dansmith | ssh timeout | |
| 13:49:33 | bauzas | either way, grenade skip-level is happy so do I | |
| 13:49:36 | dansmith | no crash | |
| 13:49:59 | bauzas | (but skiplevels are actually setting the hack option, so meh) | |
| 13:50:12 | bauzas | dansmith: ack | |
| 14:38:59 | 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 | |
| 16:06:29 | opendevreview | Merged openstack/nova stable/2023.2: Reproducer test for live migration with power management https://review.opendev.org/c/openstack/nova/+/913197 | |
| 17:07:54 | 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:30:26 | sean-k-mooney | i did ill read it now | |
| 17:31:12 | sean-k-mooney | ah so we do pull the key form barbican for cinder | |
| 17:32:35 | 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:48 | sean-k-mooney | im actully wonderign if we can tell libvirt to transfer the libivrt secret | |
| 17:33:51 | 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:34:09 | sean-k-mooney | espically when in this case its a secret passed to qemu to decrypt the disks | |
| 17:34:46 | melwitt | I tend to think sending it over RPC wouldn't be good from a security perspective | |
| 17:35:27 | 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:54 | sean-k-mooney | i assumed that is why we dont do it today by the way | |
| 17:37:19 | 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:38:19 | sean-k-mooney | thats fair. the reans we need the other is we need to update there state to refect the move | |
| 17:38:32 | sean-k-mooney | we dont need to do that for barbaican swiift or glance | |
| 17:39:03 | sean-k-mooney | which keyston neutron cinder and placement yes | |
| 17:39:42 | sean-k-mooney | that a reasonable reason to pull form barbican i just was not expecting it | |
| 17:40:15 | 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:43:35 | dansmith | maybe the answer to that is the admin should give themselves access to the secret in order to move it, | |
| 17:43:39 | dansmith | so it's in the audit log as such | |
| 17:44:05 | 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:27 | melwitt | yeah, that's how it would work today | |
| 17:49:00 | sean-k-mooney | im fine with saying for now lets keep it consitent with the ux of encypted volumes | |
| 17:49:32 | 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:50:21 | 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:51:26 | sean-k-mooney | yep makes sense to me | |
| #openstack-nova - 2024-03-22 | |||
| 03:44:45 | opendevreview | melanie witt proposed openstack/nova master: libvirt: Create persistent mdevs https://review.opendev.org/c/openstack/nova/+/910041 | |
| 13:31:24 | gibi | bauzas: is this the official ptg etherpad https://etherpad.opendev.org/p/apr2024-ptg-nova ? It is linked on https://ptg.opendev.org/etherpads.html | |
| 13:32:07 | bauzas | gibi : not yet, this is just the default one | |
| 13:32:19 | bauzas | I'll create another one today | |
| 13:33:21 | gibi | OK | |
| 13:57:27 | bauzas | gibi: done https://etherpad.opendev.org/p/nova-dalmatian-ptg | |
| 13:57:35 | bauzas | I'm gonna change the url in the ptgbot | |
| 13:58:01 | gibi | bauzas: cool, thanks for moving my content | |
| 13:59:15 | bauzas | ok, the ptg page is updated | |
| 13:59:23 | bauzas | gibi: thanks for proposing, rather :) | |
| 13:59:33 | bauzas | this was overdue | |
| 13:59:48 | bauzas | I'll tell about it next nova meeting | |
| 14:55:26 | bauzas | cores, I'd appreciate a second +2/+W on https://review.opendev.org/c/openstack/nova/+/913890 | |
| 15:05:25 | gibi | bauzas: done | |
| 15:05:38 | bauzas | thanks | |
| 16:02:27 | artom | sean-k-mooney, so as far as I can tell, we have functional tests for NUMA vSwitches | |
| 16:02:36 | sean-k-mooney | yep | |
| 16:02:41 | artom | Is the error "silent", in that we just don't pin the XML correctly? | |
| 16:02:50 | artom | Or are the tests incomplete? | |
| 16:03:16 | sean-k-mooney | want to chat about this on meet | |
| 16:03:23 | sean-k-mooney | tl;dr version | |
| 16:03:45 | sean-k-mooney | what i saw is that in the scudler i saw the log statements showing the code was runnign in the numa filter | |
| 16:04:13 | sean-k-mooney | adn i could see that the network request and numa info was correcty provide by the instace and the resouce tracker | |
| 16:04:22 | sean-k-mooney | so everything at the schduler level is working properly | |
| 16:04:29 | sean-k-mooney | fwhat i observed on the compute node | |
| 16:04:46 | sean-k-mooney | is that none of the log stames for the numa aware vswithc code paths were printing | |
| 16:05:11 | sean-k-mooney | so even thouhg both the filter and compute agaisnt call the same funtions in hardware.py | |
| 16:05:24 | sean-k-mooney | for some reasons the compute agent was not running that code | |
| 16:05:41 | artom | sean-k-mooney, https://meet.google.com/fhz-qcxz-rsy | |
| 16:05:54 | artom | (We can have that URL public, right?) | |
| 16:05:57 | sean-k-mooney | that implies that there is an issuee with the numna toplogy reqest we are generating/passing in the compute agent to that common code | |