| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-03-05 | |||
| 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 | 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:37 | sean-k-mooney | [[post-config|$NOVA_CONF]] | |
| 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 | |
| 17:08:09 | sean-k-mooney | so if your fine with doing a secret show or simialr in the api | |
| 17:08:14 | sean-k-mooney | then we can rejct it early | |
| 17:08:25 | dansmith | what I'm saying is, we should do that early and not fail deep in nova-compute once we have downloaded the image and discover we can't see the key | |
| 17:08:44 | dansmith | it would be nice to do that from the api I think, and is similar to what we do with neutron ports and things, so I don't think it's a big deal | |
| 17:08:45 | sean-k-mooney | yep thats fair | |
| 17:09:04 | dansmith | especially since unshelve is a very infrequent operation compared to something like boot | |
| 17:09:15 | sean-k-mooney | ya its simialr to the decorators we have for cybrog ectra to check api mivroversion or neutron extentions | |
| 17:10:13 | sean-k-mooney | i dont think there was a check like that in the relevent patch but i dont recall so ya proably good to capture in a comment | |
| 17:11:09 | dansmith | so now that I have that in my config, I see that devstack didn't actually deploy barbican :) | |
| 17:14:22 | dansmith | typo, I guess | |
| 17:16:51 | sean-k-mooney | so on the comptue you do not need the barbica plugin bu ton the contoler you do | |
| 17:17:05 | sean-k-mooney | i can past my contoler local.conf too for reference | |
| 17:17:42 | sean-k-mooney | https://termbin.com/6iyt | |
| 17:18:22 | sean-k-mooney | so all i have is | |
| 17:18:24 | sean-k-mooney | enable_service barbican | |
| 17:18:30 | sean-k-mooney | and | |
| 17:18:33 | sean-k-mooney | LIBS_FROM_GIT=barbican,devstack,glance,keystone,neutron,nova,placement,requirements,tempest | |
| 17:18:35 | sean-k-mooney | enable_plugin barbican https://opendev.org/openstack/barbican | |
| 17:18:51 | sean-k-mooney | + the keymanager thing i mentioned eariler | |
| 17:19:12 | sean-k-mooney | oh | |
| 17:19:23 | sean-k-mooney | i think im useing melwitt's devtack patch | |
| 17:19:47 | dansmith | yeah I typo'd the enable_service | |
| 17:19:58 | sean-k-mooney | oh that just creats flavors https://review.opendev.org/c/openstack/devstack/+/864160/10/lib/nova | |
| 17:20:01 | sean-k-mooney | so you dont need that | |
| 17:47:23 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Add debug logging to can_fit_pagesize https://review.opendev.org/c/openstack/nova/+/899942 | |
| 18:47:58 | opendevreview | OpenStack Release Bot proposed openstack/nova master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/nova/+/911270 | |
| 18:48:10 | opendevreview | OpenStack Release Bot proposed openstack/os-vif master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/os-vif/+/911272 | |
| 18:48:21 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/osc-placement/+/911274 | |
| 18:48:34 | opendevreview | OpenStack Release Bot proposed openstack/placement master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/placement/+/911276 | |
| 18:48:47 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/python-novaclient/+/911278 | |
| 18:49:55 | opendevreview | OpenStack Release Bot proposed openstack/nova master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/nova/+/911280 | |
| 18:50:07 | opendevreview | OpenStack Release Bot proposed openstack/os-vif master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/os-vif/+/911282 | |
| 18:50:19 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/osc-placement/+/911284 | |
| 18:50:31 | opendevreview | OpenStack Release Bot proposed openstack/placement master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/placement/+/911286 | |
| 18:50:45 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/python-novaclient/+/911288 | |
| 18:51:32 | opendevreview | OpenStack Release Bot proposed openstack/nova master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/nova/+/911290 | |
| 18:51:44 | opendevreview | OpenStack Release Bot proposed openstack/os-vif master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/os-vif/+/911292 | |
| 18:51:55 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/osc-placement/+/911294 | |
| 18:52:08 | opendevreview | OpenStack Release Bot proposed openstack/placement master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/placement/+/911296 | |
| 18:52:21 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/python-novaclient/+/911298 | |
| 19:27:04 | melwitt | dansmith, sean-k-mooney: are things working ok by now or are you still having issues? | |
| 19:27:40 | sean-k-mooney | i havent update my devstack in a week or two but it was workign fine for me | |
| 19:28:10 | sean-k-mooney | melwitt: i think dansmith just had a typo so i assume its working ok now or htey havent gotten aroudn to restacking | |
| 19:28:47 | melwitt | thanks sean-k-mooney | |
| 19:30:09 | melwitt | also, regarding the policy changes in the DNM tempest jobs patch, I did that to cover as many tests as possible, so that _if_ someone had their policy set that way, to verify whether it works | |
| 19:30:09 | stblatzheim | sean-k-mooney: Can you give a W vote for https://review.opendev.org/c/openstack/nova/+/910616 ? It's stuck before gate tests :) | |
| 19:30:39 | melwitt | it's not a statement about it being the right thing to do | |
| 19:31:02 | sean-k-mooney | stblatzheim: it need another stabel core to reveiw | |
| 19:31:46 | stblatzheim | Who could I ping for this? :) | |
| 19:31:57 | sean-k-mooney | melwitt: would you have 5 mins for ^ | |
| 19:31:58 | dansmith | melwitt: yeah I had a typo, not sure if it finished re-stacking or not | |
| 19:32:24 | melwitt | sean-k-mooney: sure, will look | |
| 19:32:39 | melwitt | dansmith: ack | |
| 19:33:39 | dansmith | sean-k-mooney: I looked at that yesterday and wanted to hear your take on your change of opinion | |
| 19:33:53 | dansmith | I read the bug and see neutron people saying it was wrong and implying the patch is correct, | |
| 19:34:17 | dansmith | but I didn't see any indication of "and yes this should be backported" since it presumably depends on what version(s) of neutron are in use in an older release | |
| 19:34:59 | sean-k-mooney | so the orginal patch tried to fix it by lookging for additon aports with a diffent device owner string | |
| 19:35:17 | sean-k-mooney | and i did not like that approch because it was wack a mole for every backend | |
| 19:35:31 | sean-k-mooney | the current patch checks if the subnet has dhcp enabled | |