| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-03-21 | |||
| 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 | |
| 16:06:00 | artom | I mean too late now | |
| 16:06:13 | sean-k-mooney | sure anyone is welcome | |
| 16:06:37 | sean-k-mooney | its i just wanted something higher bandwiht | |
| 16:13:10 | opendevreview | ribaudr proposed openstack/nova-specs master: Update and Re-propose "Allow Manila shares to be directly attached to an instance when using libvirt" for Dalmatian https://review.opendev.org/c/openstack/nova-specs/+/913997 | |
| 17:59:41 | opendevreview | Merged openstack/nova master: Update min support for Dalmatian https://review.opendev.org/c/openstack/nova/+/913890 | |
| 18:27:27 | opendevreview | Merged openstack/nova stable/2023.2: pwr mgmt: handle live migrations correctly https://review.opendev.org/c/openstack/nova/+/913198 | |
| #openstack-nova - 2024-03-23 | |||
| 12:09:53 | opendevreview | norman shen proposed openstack/nova master: Remove an unncessary LOG https://review.opendev.org/c/openstack/nova/+/912661 | |
| #openstack-nova - 2024-03-25 | |||
| 08:17:43 | opendevreview | Sylvain Bauza proposed openstack/nova master: Update contributor guide for 2024.2 Dalmatian https://review.opendev.org/c/openstack/nova/+/913481 | |
| 08:30:08 | opendevreview | Sahid Orentino Ferdjaoui proposed openstack/nova master: scheduler: AggregateMultitenancyIsolation to support unlimited tenant https://review.opendev.org/c/openstack/nova/+/896512 | |
| 08:30:27 | sahid | bauzas: o/ any chance to make progress on that one? | |
| 08:31:20 | bauzas | sahid: good point, thanks for your resilience :) | |
| 08:32:19 | bauzas | sahid: I'm adding the blueprint to tomorrow's nova meeting for asking to be a specless one | |
| 08:34:22 | bauzas | (added now https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting ) | |
| 09:28:35 | sahid | bauzas: thanks a lot :-) yes waiting for a while now, we have backported the patch anywy in our production but it may be useful for other users as it address a legit use-case | |
| 11:42:52 | sean-k-mooney[m] | bauzas: while i orginally was not in favor of sahid scheduler enhancement it became apparent that we would need to enchance palcement to do it any other way and that would be non trivial so im ok with proceeding with it as a specless blueprint again | |
| 11:51:18 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add missing Controller inheritance https://review.opendev.org/c/openstack/nova/+/914083 | |
| 11:51:18 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Remove FlavorManageController https://review.opendev.org/c/openstack/nova/+/914084 | |
| 12:53:13 | sean-k-mooney | bauzas: fyi this was my fun friday rabbit hole https://bugs.launchpad.net/nova/+bug/2058928 | |
| 12:53:55 | sean-k-mooney | the title says it all but we shoudl proably fix that | |
| 13:30:13 | bauzas | sean-k-mooney: looking | |
| 13:31:00 | artom | sean-k-mooney, btw, I couldn't reproduce that vswitch bug... our internal BZ isn't great on steps to reproduce, but do you recall doing anything specific? | |
| 13:31:12 | bauzas | sean-k-mooney: so we're missing instance actions, right? | |
| 13:31:46 | sean-k-mooney | bauzas: yep we never recored any in the compute manage to say if the attach/detach finished with or without an error | |
| 13:31:57 | sean-k-mooney | bauzas: so we get an instance action record with no events | |
| 13:32:35 | sean-k-mooney | i tried to make tempest use teh compeltion of the instance ation by polling and it timed out because we never actully create the finish event | |
| 13:32:55 | sean-k-mooney | we do emit the notificaitons we just dont save the event compeltion/failure in the db | |
| 13:33:34 | sean-k-mooney | we already have the remotable methods to do that including a handy class modthod on the instance_action object | |
| 13:33:43 | sean-k-mooney | we just dont call it | |
| 13:34:20 | sean-k-mooney | artom: i create a two node devstack and manually repoduced it | |
| 13:34:24 | bauzas | okay, so I guess you created a bug report for making sure we could backport it then ? | |
| 13:34:31 | bauzas | but I'm afraid of the API so | |
| 13:34:41 | bauzas | could be a interop issue | |
| 13:34:44 | sean-k-mooney | i created the bug to not loose track of this | |
| 13:35:00 | sean-k-mooney | i dont think it would be an interop thing but i wanted to discsss this at the ptg | |
| 13:35:13 | bauzas | okay, I'm asking that because I don't know whether we could rather a blueprint instead of a bug | |
| 13:35:18 | sean-k-mooney | or get gmann's input | |
| 13:35:22 | sean-k-mooney | bauzas: its not a blueprint | |
| 13:35:24 | bauzas | sean-k-mooney: I created a new etherpad | |
| 13:35:46 | sean-k-mooney | bauzas: we dont actully need to change the api | |
| 13:35:48 | bauzas | sean-k-mooney: could you add it there ? https://etherpad.opendev.org/p/nova-dalmatian-ptg | |
| 13:36:02 | bauzas | sean-k-mooney: no, I'm not saying it would change the API | |
| 13:36:02 | sean-k-mooney | there is a filed called events in teh the action record | |
| 13:36:12 | sean-k-mooney | its currently empty for at least some of the instance actions | |
| 13:36:18 | sean-k-mooney | but apprenly stop populates it | |
| 13:36:30 | sean-k-mooney | so we would jsut be populating that with event for the rest | |
| 13:36:36 | bauzas | but it would return different actions between different API versions | |