| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-03-05 | |||
| 16:30:40 | sean-k-mooney | fwiesel: basically instead of pinging you for the link on each patch i just want to find a way to look for the ci result | |
| 16:30:41 | fwiesel | That should work. I have to check, if I haven't broken it. | |
| 16:31:35 | sean-k-mooney | ack that will help us understand if the patches we are reviewing are fixing the probelmn and or breakign other things | |
| 16:32:08 | fwiesel | Yes, but the CI is not yet stable for reasons outside of the patches. | |
| 16:32:36 | sean-k-mooney | ack | |
| 16:32:49 | bauzas | ack too | |
| 16:33:06 | fwiesel | If you look at it the way that a test succeeds, then it really fixed, but if it fails, that it could be due to reasons not related to the patch, then it should be fine. | |
| 16:33:31 | sean-k-mooney | yep we cant know if a fialure is infra related or not | |
| 16:33:47 | sean-k-mooney | but if a previsoly broken functionlity passes we know ti appears to work | |
| 16:34:05 | fwiesel | ack | |
| 16:34:44 | fwiesel | Tomorrow, I'll make then sure that the index is still correctly updated. | |
| 16:35:43 | fwiesel | That's from my side then. Any other questions? | |
| 16:36:37 | fwiesel | back to you then, bauzas | |
| 16:36:43 | bauzas | cool | |
| 16:36:48 | bauzas | #topic Open discussion | |
| 16:36:50 | bauzas | . | |
| 16:36:56 | bauzas | anything else ? | |
| 16:37:22 | sean-k-mooney | are we going to merge https://review.opendev.org/c/openstack/nova/+/902687 and the patch beloew | |
| 16:37:40 | sean-k-mooney | you said you wanted to wait until after FF | |
| 16:38:05 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/899753/11 for pyproject.toml supprot need a devstack patch so that can wait until D | |
| 16:38:34 | sean-k-mooney | but shall we proceed with the addtion of supprot for wsgi module loading | |
| 16:39:12 | bauzas | I'll look at those patches indeed | |
| 16:39:23 | sean-k-mooney | cool that was all i wanted to raise | |
| 16:39:28 | bauzas | and I'll move those in the etherpad to the bugfixes section | |
| 16:40:07 | bauzas | anything else before we close ? | |
| 16:40:26 | bauzas | looks not | |
| 16:40:31 | bauzas | thanks all | |
| 16:40:34 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-03-05-16.00.log.html | |
| 16:40:34 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-03-05-16.00.txt | |
| 16:40:34 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-03-05-16.00.html | |
| 16:40:34 | opendevmeet | Meeting ended Tue Mar 5 16:40:34 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:40:34 | bauzas | #endmeeting | |
| 16:40:39 | elodilles | thanks o/ | |
| 16:40:44 | fwiesel | thanks | |
| 16:41:27 | auniyal | sean-k-mooney, bauzas can you please have another look on these https://review.opendev.org/c/openstack/nova/+/891289 | |
| 16:42:39 | sean-k-mooney | i was holding off on that because it was conflicting with the manila share and ephmeral encyption series | |
| 16:43:03 | sean-k-mooney | it has both object and rpc bumps | |
| 16:43:17 | sean-k-mooney | so we should wait until we reopen master for deveopment after RC1 | |
| 16:44:05 | sean-k-mooney | the previous patch however https://review.opendev.org/c/openstack/nova/+/877446 could be reviewd | |
| 16:44:59 | sean-k-mooney | thats a valid backportable bug fix so ill take a look but ill defer to bauzas wither we want to incldued it for rc1 | |
| 16:45:54 | bauzas | sounds to me a bugfix | |
| 16:45:59 | bauzas | so yeah looks a possible RC1 patch | |
| 16:46:41 | sean-k-mooney | this is an enhancemnt based on feed back form gorka and other using the volume refrsh commands | |
| 16:47:08 | sean-k-mooney | it adresses one of the issues they had when they actully tried to use it so its a nice addtion | |
| 16:47:45 | bauzas | I don't see it in the etherpad | |
| 16:47:49 | bauzas | so I'll add it | |
| 16:48:04 | auniyal | sean-k-mooney, bauzas ack thanks | |
| 16:50:29 | auniyal | bauzas, its there at the end, earlier I had added only the top one 891289, now added other one as well | |
| 16:51:07 | sean-k-mooney | bauzas: stephenfin is +2 and i just reviewd it and my previous comments have been adressed so i approved https://review.opendev.org/c/openstack/nova/+/877446 | |
| 16:52:05 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/891289/10 however need more care. we could include the change in RC1 but this is not backporatble | |
| 16:52:22 | sean-k-mooney | so there is an agument to be made that we shoudl try and include it in the slurp release | |
| 16:55:15 | dansmith | melwitt: sean-k-mooney trying to deploy the EE set locally and I get this: nova.exception.KeyManagerError: Key manager error: cannot store arbitrary keys | |
| 16:55:18 | dansmith | from n-cpu | |
| 16:55:43 | dansmith | I didn't apply the barbican policy changes from the jobs, which I think are just for admin access during unshelve | |
| 16:55:54 | sean-k-mooney | you dont need the policy chnage | |
| 16:56:03 | sean-k-mooney | but you do need to enable barbican in nova's config | |
| 16:56:40 | sean-k-mooney | [key_manager] | |
| 16:56:41 | sean-k-mooney | fixed_key = bae3516cc1c0eb18b05440eba8012a4a880a2ee04d584a9c1579445e675b12defdc716ec | |
| 16:56:43 | sean-k-mooney | backend = barbican | |
| 16:56:49 | sean-k-mooney | you do not need the fixed_key line | |
| 16:56:50 | dansmith | ahh, okay that must be it | |
| 16:57:00 | sean-k-mooney | just backend = barbican | |
| 16:57:16 | dansmith | I was asking melwitt what all I needed from those jobs, and I thought it was just the devstack plugin for barbican | |
| 16:57:37 | sean-k-mooney | [[post-config|$NOVA_CONF]] | |
| 16:57:37 | dansmith | that should probably go in either in the plugin or in lib/nova and not just be in the job def itself | |
| 16:57:39 | sean-k-mooney | [key_manager] | |
| 16:57:41 | sean-k-mooney | backend = barbican | |
| 16:57:43 | sean-k-mooney | i have that in my local.conf | |
| 16:57:47 | dansmith | ack | |
| 16:58:16 | sean-k-mooney | [[post-config|$NOVA_CPU_CONF]] woudl be more correct but both will work in this case | |
| 17:00:22 | sean-k-mooney | https://termbin.com/i869 that my local.conf form my comptue althoug hi think i made some changes after the fact i.e. i checkout diffent nova banches and restarted the services | |
| 17:01:04 | dansmith | I'm kinda wondering about the whole unshelve-by-admin thing and the required policy change | |
| 17:01:06 | sean-k-mooney | i have a lot of stuff set in that local.conf since i used the one form the ci job as a base | |
| 17:01:23 | sean-k-mooney | well admins proably should not be able to unshleve | |
| 17:01:30 | dansmith | that seems like the kind of thing that security people would discourage, so I wonder if we can just block that case and say "the user has to do it" | |
| 17:01:33 | dansmith | right exactly | |
| 17:01:34 | sean-k-mooney | they cant as far as ia aware with cinder encypted volumes | |
| 17:01:48 | dansmith | ++ | |
| 17:02:06 | sean-k-mooney | right os melaniy was just checkign that it could work but not suggesting that we should do that | |
| 17:02:27 | sean-k-mooney | i gave similar feedback before that i would prefer not to use custom policy for barbican in the final jobs | |
| 17:02:32 | dansmith | there's existing plumbing to make it work, no? | |
| 17:02:40 | sean-k-mooney | and just skip the admin tests that dont work | |
| 17:03:32 | sean-k-mooney | mels code in nova would support the usecase if barbican's policy allowed it, if that is what you mean | |
| 17:03:37 | dansmith | I haven't made it past the create patch, but IIRC there was stuff in there to support the admin case I thought | |
| 17:03:58 | sean-k-mooney | only if you teak the policy | |
| 17:04:07 | dansmith | right, but see what I'm saying is, maybe we should refuse it early at the api or conductor level and not fail only when we can't access the key | |
| 17:04:13 | sean-k-mooney | it will only work for an admin otherwise if they own the vm | |
| 17:04:42 | sean-k-mooney | ya thats a possibelity i was doing most of my testing as admin demo | |
| 17:05:07 | sean-k-mooney | by the way did no know devstack generate a clouds.yaml with multipel diffent profiles/users | |
| 17:05:24 | dansmith | I think, if we can tell from the api, a "409: Can't unshelve this encrypted instance" would be much nicer | |
| 17:05:45 | dansmith | yes, that's how I get admin now, because that's the "proper way" AFAIK | |
| 17:05:47 | sean-k-mooney | i dont think we can detect that | |
| 17:06:20 | dansmith | we have the image properties in instance system meta right? if we haven't updated it with the encryption secret, we could/should right? | |
| 17:06:42 | sean-k-mooney | yes but that not enough | |
| 17:07:00 | sean-k-mooney | what we actully need to know is if barbican is using custom policy or not | |
| 17:07:34 | sean-k-mooney | and we need to know that the admin that is making the request is doing so with a token that does not have access | |
| 17:07:44 | dansmith | we can grab the secret uuid and see if we can show it, or we can say "you don't own this and its encrypted so I'm not even going to try" | |
| 17:07:45 | sean-k-mooney | so really we would have to try and get the secret in the api | |
| 17:07:49 | sean-k-mooney | and bail early if that fails | |
| 17:07:57 | sean-k-mooney | ya | |