14:01:35 #startmeeting glance 14:01:35 Meeting started Thu Jul 10 14:01:35 2025 UTC and is due to finish in 60 minutes. The chair is croelandt. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:35 The meeting name has been set to 'glance' 14:01:39 #topic roll call 14:01:40 o/ 14:01:54 o/ 14:02:32 hi 14:03:18 o/ 14:03:27 abhishekk: around? :) 14:03:33 o/ 14:03:34 I think dansmith is out today 14:03:45 #topic Release/periodic job updates 14:03:53 So we have support for Centos 10 now 14:04:03 #link https://review.opendev.org/c/openstack/devstack/+/937251 14:04:08 ^ this patch needs to be updated and reviewed 14:04:20 I have just talked to the author, and they are not working on this anymore, so I'll take over the patch 14:04:36 I wonder if we could not just use PYTHON3_VERSION like they do at https://github.com/openstack/devstack/blob/master/.zuul.yaml#L733 14:04:42 #link https://github.com/openstack/devstack/blob/master/.zuul.yaml#L733 14:04:57 which would have been simpler :) But I guess soon we'll want to migrate to CentOS 10 anyway 14:05:51 #topic Encryption 14:05:59 so the main thing for this week is image encryption 14:06:05 mhen: we've reviewed your patch and it looks pretty good 14:06:14 thanks for reviewing! 14:06:20 I think my main concern is that dansmith had some things to discuss, I'll make sure to remind him on Monday when he is back 14:06:32 understood 14:06:36 oh and there was my point about the tests still using cinder_encryption_* 14:06:40 not sure if that is intentional 14:06:47 I answered this some minutes ago 14:07:33 it is intentional, I think we want to make sure those attributes still work for some potential edge cases during the deprecation timeframe 14:07:56 ok 14:08:05 I wonder if we could refactor some tests though 14:08:20 def test_something(self, key): for instance 14:08:27 but maybe that is going to overcomplicate things 14:09:47 as the patchset is currently done, all test methods concerning the old names are suffixed wiht "_deprecated" 14:09:56 they are easy to spot (and remove, in the future) 14:10:31 oh ok 14:10:36 let's not change anything then :) 14:11:43 Anything to add on this topic? 14:12:10 not from my side 14:12:24 #topic Open Discussion 14:12:28 abhishekk: anything else? 14:12:48 hi, i wanted to follow up on https://review.opendev.org/c/openstack/glance-specs/+/953435 14:12:55 Nope, I have nothing this week 14:13:20 looks like glance is project scoped service and not domain scoped token 14:13:45 ok 14:13:59 hence the get_image doesnt have a domain_id 14:14:12 any suggestions on how to proced ? 14:14:39 I don't think we are ready to move at domain scope, that will be huge chnage 14:14:49 have other projects done that? 14:14:58 i had no luck with https://github.com/sapcc/glance/commit/ed9817df7ba9fb6d9bbd4b51adfcb4c3bcc28fe5 14:15:38 my intent is to restrict public images to a particular domain, last option is to filter via project_id (which is like 300+ projects) 14:15:39 Certainly we can discuss this next PTG 14:15:49 --tags, --hidden isnt an option 14:16:19 okay, isnt there any other option ? 14:16:33 rajiv: have other projects done that? 14:17:05 code enhancements wouldnt work since domain_id isnt there in get_image, the transformer uses owner info as project_id 14:17:15 croelandt: i looked around but found none 14:17:32 there are few custom projects which use oslo 14:18:02 how can i use https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L165 ? 14:18:02 "As OpenStack evolves toward better domain-scoped operations and identity management" <- what is your source for this? 14:18:43 Keystone recently added the "manager" persona for domains: https://docs.openstack.org/keystone/latest/user/domain-manager-usage.html 14:18:53 rajiv: so is your goal that a user U in domain D does a image-list, they should only see images that are owned by entities that are also in domain D? 14:19:58 rosmaita: user U cannot list public images in a particular domain but works in other domains 14:20:07 shouldnt* 14:20:17 but can list private or shared images 14:20:41 in other words, implement public image visibility to users in a particular domain 14:21:18 rajiv, private image of domain d should be listed by user in domain U? 14:21:39 abhishekk: yes, only restrict public image view 14:22:08 so at least part of the problem is that this is completely different from the glance image ownership model 14:22:34 images are owned by projects, but images are not "in" a domain 14:22:34 yes, I would say opposite as well 14:23:47 i couldnt find a way to fetch domain id info into glance 14:24:08 if there was a way, i could map project id to domain id to solve this request 14:25:07 glance doesn't have any domain info, that is kept in keystone, because domains are a way of grouping users 14:25:15 or are there suggestions to fetch domain info into glance ? 14:25:47 true, i am also open on how to implement restrictions for public images. 14:27:24 any comments on the approach of this commit ? or it makes no sense since domain is not supported at all ? 14:27:25 https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L165 14:27:31 well, you could just not have any public images, and instead have a special user per domain that owns the "public" images for that domain, and that special user would share the images with all the projects in that domain 14:28:40 rosmaita: could you please elaborate ? 14:28:54 i will try :D 14:29:02 :) 14:29:22 ok, so let's say there is user A in domain AA, and user B in domain BB 14:29:33 we don't want A to see public images for BB 14:29:45 so, we don't make any glance images public 14:30:12 instead, we create a special user in keystone, UA in domain AA 14:30:26 all users AA shouldnt view public images, but can view private, shared, etc. Its not cross domains 14:30:42 then UA uploads all the images to glance that should be "public" in AA 14:30:53 then UA shares these images with user A 14:31:00 now, user A can see the AA images 14:31:07 but user B cannot 14:31:17 and you do the same thing for domain BB 14:31:42 the problem is that you have to manage the image sharing, but that could be automated, i think 14:31:55 (automated by the operator, not by glance) 14:32:14 thanks, to clarify Domains AA, BB, CC 14:32:28 users in Domain AA cannot view public images 14:32:39 Domain BB,CC works like default 14:32:47 only because there are no public images at all for any domain 14:32:58 restriction of public image view is only on Domain AA 14:33:49 no, we are not restricting public image view at all ... what we are doing is not having *any* public images 14:34:09 public image view is mandatory in other domains :) 14:34:18 not sure what you mean 14:34:48 I think they want an isolated domain that has its own images but cannot see public images (which all other domains do)? 14:34:50 to clarify Domains AA, BB, CC ; users in Domain AA cannot view public images; 14:35:03 Domain BB,CC works like default 14:35:12 mhen: correct 14:35:14 means they can view public images 14:36:21 well, sounds like you need a dedicated glance or something 14:38:28 okay, glance per isolated domain ? 14:39:04 i guess ... isolated glance in an isolated domain 14:40:15 oh, thats more complicated than i imagined :( 14:40:41 your requirement is also complicated :D 14:41:28 haha true! 14:41:48 lastly, there is no way to import domain_id into glance, right ? 14:42:44 not sure, need to check 14:44:16 any clue how owner info is populated ? 14:44:30 probably by oslo.context 14:45:00 i mean, there's some glance code, but it uses oslo.context 14:45:23 okay, in this case, domain_id should also be possible ? since oslo.context has domain_id https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L165 14:46:33 https://opendev.org/openstack/glance/src/branch/stable/2024.2/glance/context.py#L80-L83 ? 14:47:35 rajiv: https://github.com/openstack/glance/blob/master/glance/api/middleware/context.py#L125 14:48:18 IF you print req.environ here before line 148, you will see domain information there 14:49:35 okay sure, i can look into this direction 14:50:04 the problem is going to be that images do not have a domain_id 14:50:57 and aren't keystone domains fluid, that is, projects can be added and removed to domains? 14:51:00 yep, i fear the same 14:51:07 exactly, I told him, but not sure what he has in mind 14:51:43 yeah, my understanding is that keystone domains group users/projects, but not resources 14:52:42 if i am able to fetch domain_id, then i can introduce another logic to validate the project & domain_id mapping > then maybe in get_image 14:53:00 restriction via policies is the cleanest way right ? 14:53:49 you need lot of tweaks for this to happen 14:54:08 true 14:55:17 enhance alembic as well, the list goes on! 14:56:03 that's why I said, gather requirements and come back in PTG with detailed information 14:56:22 roger :) 14:56:47 over and out :D 14:56:48 this is the requirement though :) 14:56:55 thanks for your time! 14:57:06 np! 14:57:12 right in time \o/ 14:57:15 #endmeeting