14:00:03 <abhishekk> #startmeeting glance
14:00:04 <opendevmeet> Meeting started Thu Jun  3 14:00:03 2021 UTC and is due to finish in 60 minutes.  The chair is abhishekk. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:05 <abhishekk> #topic roll call
14:00:06 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:08 <jokke_> o/
14:00:09 <opendevmeet> The meeting name has been set to 'glance'
14:00:10 <abhishekk> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:00:15 <abhishekk> o/
14:00:41 <dansmith> o/
14:00:55 <abhishekk> lets wait couple of minutes for others to show
14:01:11 <rosmaita> o/
14:01:35 <abhishekk> I think Steap will join us soon, till then we can start with the updates
14:01:40 <abhishekk> #topic release/periodic jobs update
14:01:52 <abhishekk> M2 is 6 week away
14:02:19 <abhishekk> we are going to target at least 2 main specs in this period
14:02:54 <abhishekk> which we will discuss in next topic
14:02:59 <abhishekk> Periodic jobs all green for straight 4th week
14:03:27 <rosmaita> \o/
14:03:35 <abhishekk> yes \o/
14:03:45 <abhishekk> no timeouts at all
14:03:49 <jokke_> nice
14:04:08 <abhishekk> cool, lets move to next topic
14:04:13 <Steap> o/
14:04:32 <abhishekk> #topic Deadlines and review volunteers
14:04:54 <abhishekk> As decided/discussed in last week, we will be finalizing deadlines for 2 specs
14:05:06 <abhishekk> 1. Unified quota spec
14:05:14 <abhishekk> The spec is owned by dansmith
14:05:42 <abhishekk> Spec is approved in this week and implementation patches are up for review
14:06:13 <abhishekk> I am Expecting to be completed - M2 - 1 week i.e. 1 week before Milestone 2
14:06:53 <abhishekk> Voluntary reviewers: abhishekk, Steap (as Steap agreed to help us on reviews)
14:07:07 <abhishekk> we need one additional voluntary core reviewer for this
14:07:24 <dansmith> can I volunteer rosmaita or does he have to do it? :)
14:07:50 <rosmaita> you can volunteer me
14:07:53 <abhishekk> Any one up for volunteer from rosmaita or jokke_ ??
14:08:11 <dansmith> seems natural to have the spec +2ers be the code reviewers
14:08:23 <abhishekk> cool, then jokke_ will be standby reviewer
14:08:27 <abhishekk> yes
14:09:14 <abhishekk> In case one of the voluntary core is not available then standby core needs to step up
14:09:37 <abhishekk> dansmith, as a owner are you comfortable with deadline decided?
14:09:48 <dansmith> sure, the only thing that isn't up yet is docs
14:10:10 <dansmith> which I need to get going on now that we have settled all the design and behavior
14:10:27 <abhishekk> ack, so 1st one is final
14:10:33 <abhishekk> Lets move to 2nd one
14:10:53 <abhishekk> Cache API, Move cache operations under glance API
14:11:03 <abhishekk> Owner is jokke_
14:11:19 <abhishekk> Spce is already approved by 2 cores, dansmith and jokke_
14:11:32 <abhishekk> I need to come up with lite-spec for glanceclient changes
14:11:44 <abhishekk> Voluntary reviewers:
14:12:04 <abhishekk> I am considering dansmith and Me as a primary reviewers for this spec
14:12:14 <dansmith> sure
14:12:18 <abhishekk> great
14:12:32 <abhishekk> Steap, and rosmaita will be on standby for the same
14:12:50 <dansmith> can we go ahead and merge the spec? there's not much code up, so I assume merging the spec will allow that to proceed
14:12:59 <abhishekk> Steap, also has better knowledge of glance-cache so his inputs will also help us
14:13:11 * Steap has got to sit down and read more patches
14:13:34 <abhishekk> dansmith, yes, I will approve it after the meeting
14:13:41 <dansmith> cool
14:13:48 <abhishekk> Expected to be completed - M2 - 1 week
14:14:03 <abhishekk> jokke_, are you comfortable with the deadline?
14:14:48 <jokke_> I'll likely need help figuring out how to test this, but the code itself is going to be pretty straight forward
14:15:20 <abhishekk> cool, we can work on testing part
14:15:24 <dansmith> it should be easy to test
14:15:42 <rosmaita> should probably add tempest tests for the new API and then they can be proposed as recommended items for interop
14:15:56 <dansmith> just looking at tempest/api/image/v2/test_images should be pretty instructive, but I can help with that
14:16:03 <dansmith> rosmaita: yep, noted in the spec :)
14:16:08 <abhishekk> ++
14:16:18 <rosmaita> guess you can tell that i am behind on my reviewing
14:16:25 <abhishekk> :D
14:16:34 <jokke_> rosmaita: that's IMO for next cycle as it's planned EXPERIMENTAL for this cycle
14:16:55 <abhishekk> No, rosmaita we are grateful for your efforts in glance
14:17:45 <abhishekk> SO, apart from these priorities specs we also need to keep reviewing other patches as well
14:17:53 <abhishekk> kindly don't forget that :D
14:18:10 <dansmith> so one related thing,
14:18:35 <dansmith> I think it would be nice if we're adding new APIs (the cache ones) to make them use a modern policy enforcement
14:18:39 <abhishekk> Also, each week we will discuss the progress of the work
14:19:47 <jokke_> dansmith: I think we need to policy it both ways, no?
14:19:51 <dansmith> so I wonder if it's worth stacking a refactor of the cached_images enforce under the actual patch to add those new APIs?
14:19:53 <abhishekk> dansmith, If the new policy enforcement framework is up, running and approved until then there is no issue
14:20:51 <dansmith> abhishekk: well, right I'm just asking about trying to dovetail those two efforts
14:21:02 <dansmith> I'll have to go look at what cached_images does now I guess
14:21:29 <dansmith> I think it was just a single policy rule with no details such that you grant all or nothing to some role
14:21:59 <abhishekk> jokke_, what do you mean by both ways?
14:22:38 <dansmith> abhishekk: in your spec you called out the new rules, so I guess when we see the code for the api bit to use those rules we can go from there
14:22:50 <jokke_> dansmith: if you end up playing around with it, just that you know. Currently the code is under api/v2/, but the API itself is exposed through the cahcemanagemnt middleware that works together with the cahing middleware. It's bit cumbersome, but that's how you can enable it for poking around
14:23:41 <jokke_> abhishekk: I guess we need to have both checks, legacy glance policy and rbac checks for those endpoints
14:24:43 <dansmith> I don't know what that means
14:24:46 <abhishekk> jokke_, we don't need special arrangement for that, if rbac is disabled then it will enforce the policy in legacy format
14:25:57 <jokke_> dansmith: so the two middlewares needs to be in your paste pipeline for that current cache management API to show up
14:26:11 <dansmith> I mean the policy thing
14:27:44 <abhishekk> I think there is some confusion here with rbac and legacy policy
14:28:23 <abhishekk> jokke_, do you mean we need to test the same with rbac as well as legacy policy enforcement?
14:28:37 <jokke_> dansmith: so I think the new policy keys makes sense to be enforced at the API, then I just need to figure out how to work around so the old and new policies do not break eachother
14:29:14 <jokke_> so likely easiest is to move the policy enforcement to the middleware where the API is exposed too to avoid either execution path going through both of them
14:29:50 <dansmith> I guess I need to look at this closer
14:30:14 <jokke_> abhishekk: yeah, I think it would be very wrong of us to implement new API endpoints and not take the rbac work into account during the implementation
14:31:00 <abhishekk> jokke_, ack, but I think we don't need to follow onion layer for these APIs for some reasons
14:31:29 <dansmith> yeah, sounds like we agree on the goal at least
14:31:40 <abhishekk> I mean for the new cache APIs
14:31:55 <dansmith> this API seems like a good one to have all the policy enforced at the api layer, which might already be the case, but needs some rbac love
14:32:12 <dansmith> implementing it all in middleware seems wrong to me, but I need to look and see how that's all done I guess
14:32:27 <jokke_> abhishekk: I thought it was agreed already ages ago that we avoid adding anythin we don't strictly need to the onion hell
14:32:47 <abhishekk> ok, I will keep the spec on hold till then
14:33:03 <abhishekk> I would like to explain this policy stuff with rbac in the spec
14:33:12 <jokke_> dansmith: so the problem is the middleware is exposing the current api which is moving to the api/v2/mapper
14:33:47 <jokke_> dansmith: we're planning to deprecate the cachemanagement middleware, so while it's deprecated it still needs to enforce it's current policies
14:34:13 <jokke_> but as we agreed to put new clearly defined policy keys in place we need to avoid overlapping those two
14:34:56 <dansmith> did the old cachemanage hit APIs implemented in middleware?
14:35:03 <dansmith> I had assumed it twiddle the db directly
14:35:27 <jokke_> dansmith: correct the cachemanagement middleware injected it's api endpoints
14:35:41 <jokke_> that's why we are refactoring this to clean it up
14:35:47 <dansmith> right, but.. I didn't realize the manage tool hit those I guess
14:36:03 <dansmith> so the spec doesn't very clearly articulate that existing apis are going to be moving, and the one code patch that is up just adds new ones,
14:36:13 <dansmith> so I guess that's why I failed to grasp the moving aspect
14:36:24 <rosmaita> i missed that part as well
14:36:34 <dansmith> I'm still not sure what that has to do with what we do for policy though
14:37:05 <jokke_> yeah, since few cycles ago, it had something to do about getting rid of registry and v1 api that changed it in a way that poking stuff directly got painful
14:39:14 <dansmith> jokke_: do you have more code for this sitting in the wings that you could push up to better show what all is going on?
14:39:14 <jokke_> dansmith: they are sharing the functional code, and I'm pretty sure the old policies for it are enforced quite deep in that code. So to be able to introduce the policy keys and enforce the at API layer we need to make sure we don't get hit by the old policies down in the chain but also make sure they still get enformced in the middleware is in play
14:39:31 <abhishekk> https://review.opendev.org/c/openstack/glance/+/626097
14:40:02 <abhishekk> this was the code to fix cache-manage when v1 was removed
14:40:09 <jokke_> dansmith: no, I literally whipped that one patch for abhishekk to have an idea how we could consolidate the functionality under one /v2/cache endpoint
14:40:30 <dansmith> okay
14:40:39 <abhishekk> https://review.opendev.org/c/openstack/glance/+/626097/5/glance/api/v2/cached_images.py
14:41:03 <abhishekk> This is the existing policy manage_image_cache jokke_ is talking about
14:41:23 <dansmith> right
14:41:52 <abhishekk> so this is also injected at API side I guess
14:42:08 <dansmith> well, this _enforce method is what I was concerned about earlier:
14:42:13 <dansmith> self.policy.enforce(req.context, 'manage_image_cache', {})
14:42:21 <dansmith> this is one policy element for the whole thing with no target,
14:42:35 <dansmith> which means you can delegate cache management to a role, but with no control beyond that
14:42:54 <abhishekk> ack
14:43:11 <jokke_> dansmith: yup, that's why we discussed about splitting that policy to individual components.
14:43:15 <dansmith> for things like queue_image we should be passing the ImageTarget there so you can allow people to cache their own images, but not others (if that's what you want)
14:43:36 <dansmith> jokke_: it's more than that though
14:43:42 <dansmith> but that's an important part, of course
14:43:47 <abhishekk> So definitely spec need some additional information
14:44:04 <dansmith> for the rbac part that would be good, yeah,
14:44:19 <abhishekk> Can either of you comment on the spec, I will update it then
14:44:20 <dansmith> but abhishekk maybe you can put more detail in there too about the middleware->api spec?
14:44:29 <dansmith> er, s/spec?/part/
14:44:29 <abhishekk> yes
14:44:32 <dansmith> cool
14:44:38 <jokke_> dansmith: basically the assumption has been as it needs to be done node by node basis that all cache management has been done by admin or admin-like operator responsible for the cache management in the cloud (In reality very little by hand management happens anywhere I know of)
14:45:12 <dansmith> right, but the point of rbac is to allow for less-than-god-like admins to manage certain spheres of responsibility
14:45:36 <jokke_> dansmith: which i why I said we need to take that into account for this work
14:46:20 <jokke_> would be very wrong of us to make this new API endpoint and not implement it with rbac in mind from get go
14:46:36 <dansmith> I think we're agreeing...?
14:46:42 <abhishekk> Ok, I will update the spec with this
14:47:15 <abhishekk> we agreed :D
14:47:38 <abhishekk> Moving to next topic now
14:47:47 <abhishekk> #topic Metadef project scope implementation
14:47:53 <abhishekk> Should we start parallel with policy refactoring?
14:48:22 <abhishekk> Metadef has 5 to 6 APIs which are pending for project scope implementation
14:48:24 <jokke_> dansmith: I think that's something at least I just assumed as impementation detail rather major design aspect ... Just expecting that all new API work we do needs to take rbac into consideration like we just assumed that policies needs to be taken into account before without necessarily specifically calling it out in a spec ;)
14:48:48 <abhishekk> and we need to complete project scope for glance in this cycle
14:48:52 <dansmith> abhishekk: are you talking about fixing some metadef CRUD APIs so they can be safe to allow project people to manage?
14:49:28 <dansmith> jokke_: okay, well, the spec is kinda for level-setting assumptions, so... :)
14:49:28 <abhishekk> yeah
14:49:50 <dansmith> abhishekk: I'm not sure that's worth the effort unless there's someone that is asking for it
14:49:52 <abhishekk> I have one associate who is willing to work on this metadef part
14:50:35 <dansmith> is someone asking for it? it sounded like 99% of people just leverage the inbuilt metadefs for things like horizon, and one entity spoke up (CERN) about updating them, but they were assuming admin-only anyway
14:51:35 <abhishekk> dansmith, nope no one is asking but its a target given to at least complete implementation of project scope for this cycle
14:52:31 <dansmith> okay, but if we just delcare that this is not a project-scope-able API then ... it doesn't matter right?
14:52:57 <jokke_> My biggest concern with the whole rbac picture atm. is that when you turn that on we loose our 'admin' and we have lots of things that assumes admin overwrites and adminnes baked into our API. Like with just project scope implemented Glance will be very very broken service with rbac turned on
14:53:59 <dansmith> well, that's why it's a big effort (for all projects) and why they pay us the medium bucks to fix it right? :)
14:54:04 <jokke_> and none of that translates to project admin
14:55:36 <abhishekk> 5 minutes, we can revisit this next week
14:55:40 <abhishekk> with more information
14:55:45 <abhishekk> #topic Open discussion
14:56:01 <abhishekk> is something missed?
14:56:06 <abhishekk> whay bot is not working ?
14:57:02 <abhishekk> so bots are not working since the begging
14:57:22 <rosmaita> looks like it crashed after #startmeeting
14:57:24 <dansmith> looks like it started the meeting,
14:57:25 <dansmith> but yeah
14:57:36 <dansmith> crashed setting topic maybe :)
14:57:44 <abhishekk> anything for open discussion?
14:57:46 <rosmaita> btw, i'll be away all next week, so will miss the meeting :)
14:57:48 <jokke_> abhishekk: well it reported starting meeting ... might be that the oftc services are not exact compatible for topic setting or something
14:57:52 <jokke_> fungi: ^^
14:58:05 <abhishekk> I think so
14:58:28 <abhishekk> I think some1 should have noticed it earlier
14:58:30 <jokke_> Monday is Bank Holiday here, so I'll be around 4 days next week
14:58:31 <fungi> yes, if you followed the announcements on the service-discuss ml, the meetbot can't currently alter channel topics
14:58:53 <fungi> we're rewriting the bot to interact with chanserv via privmsg to do it
14:58:56 <abhishekk> :D, thank you for the update
14:59:21 <abhishekk> jokke_, cool, have a nice weekend
15:00:07 <abhishekk> Ok, time is up
15:00:09 <abhishekk> thank you all
15:00:15 <jokke_> thanks!
15:00:19 <abhishekk> #endmeeting