14:00:14 #startmeeting glance 14:00:15 Meeting started Thu Nov 19 14:00:14 2020 UTC and is due to finish in 60 minutes. The chair is abhishekk. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:15 #topic roll call 14:00:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:18 The meeting name has been set to 'glance' 14:00:20 o/ 14:00:24 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:00:27 o/ 14:00:33 Short agenda today 14:01:01 Might be finished within 15-20 minutes 14:01:35 waiting couple of minutes for others to join 14:02:59 Looks like just us :D 14:03:01 lets start 14:03:07 :) 14:03:14 #topic release/periodic jobs update 14:03:20 Wallaby milestone 1 - 2 weeks away 14:04:01 I am going to tag glance-store release next week on Monday to unblcok cinder multistore functional tests 14:04:09 Periodic jobs 1 failure this week 14:04:21 Will go through logs after the meeting 14:04:41 kk, was jus gonna ask if something we need to be worried about or just glitch 14:04:44 o/ 14:04:50 Hi Brian 14:04:56 o/ 14:05:01 sorry i'm late 14:05:03 no need to worry at the moment 14:05:10 no problem rosmaita :D 14:05:23 #topic Milestone 1 priorities 14:05:32 Reform cluster awareness specs 14:05:48 Reform cache-api specs (very less priority) 14:06:00 Lite spec for task API for general user (mostly just like task show API) 14:06:24 I will try to put this lite spec by Monday, at the moment working on PoC 14:07:02 Other than this, kindly go through glance-specs patches, I have asked couple of contributors to file lite specs for their work 14:07:13 I will have the cluster awareness spacs up either today or tomorrow, likely today 14:07:20 cool 14:07:36 Moving ahead 14:07:44 #topic RBAC 14:07:58 everybody's favorite topic! 14:08:04 :P 14:08:19 I have attended Open hour meeting this week and cleared some of my doubts 14:08:28 No need to have policies close to API layer 14:08:48 At the moment they said there is no need to refactor our policy layer much 14:09:02 WIP patch - https://review.opendev.org/763208 14:09:32 I will discuss this patch with lbragstad for the inputs and direction 14:10:10 Upstream goal wise we are on track and just need to submit one reno saying we are using policy.yaml than policy.json 14:10:40 This we will address while releasing milestone 1 for glance 14:10:51 yeah 14:11:09 Is the upstream goal for W to implement the 4 "basic" persona? 14:11:26 i think there are 5? 14:11:41 Upstream goal for W is to use policy.yaml instead of policy.json 14:11:46 3 project scope, 2 system scope 14:11:50 o/ 14:12:16 o/ 14:12:31 lbragstad, I have added you as a reviewer to WIP patch 14:12:51 kindly have a look and let me know your suggestions 14:13:05 will do - thank you for starting that process abhishekk 14:13:10 rosmaita: damn, on Tuesday it was 4, now it's 5 14:13:29 Steap: it's almost as bad as covid 14:13:32 the 5th is kind of a noop 14:13:48 lbragstad: what do you mean? 14:14:07 lbragstad, no worries, there is lot to do :D 14:14:14 so - we have system admin, system member, system reader, project member, and project reader 14:14:37 lbragstad: so system-member is useless, but project admin is ++ 14:14:44 no project admin? 14:15:05 based on feedback from the groups we've talked to so far, project admin is something we can do later 14:15:22 rosmaita and yes, system-member is essentially another name for system-reader since member implies reader 14:15:47 but - it is useful if a deployment wants to offload some administrative functionality from system admin to system member (all they have to do is supply the override) 14:15:59 well, and test the heck out of it 14:16:12 ++ 14:16:17 ok, but the key issue is what personas are "required"? 14:16:34 system admin, system reader, project member, and project reader 14:16:50 ok, cool 14:17:07 everything that "project admins" do today should get refactored into system admin 14:17:26 rosmaita: abhishekk: didn't we remove the "tenant_is_owner" config option and made it default? And IIUC project == tenant so we we should not have anything different between project member and project admin, the reader is going to bitch and a half to ensure 14:17:57 jokke: we deprecated it, now sure if it was actually removed 14:18:19 Need to check whether we have removed it or not 14:18:41 ^^ and od we have migration in place for those who did use user as owner :| 14:18:47 jokke can you elaborate on the concerns for reader? 14:18:54 no, we were not going to do a migration 14:19:01 i think we said so in the deprecation notice 14:21:15 lbragstad: our policies are all over the place between API and actual db calls. To actually ensure that there is no changes to happen for what ever gets scoped as reader is not just looking the API call type. Specially as we have lazy store converts in a place that would cause even normal listing by reader to be denied 14:21:41 ok - interesting... 14:21:54 jokke: just checked, deprecation specified no migration path : https://review.opendev.org/#/c/552642/ 14:22:33 i need to take a harder look at glance - but i'll see if i can scrub up an example 14:22:38 rosmaita: hmm-m ok was it just deprecated as signalling "please, don't use" or were we actually planning to remove that? 14:22:45 well, actually the deprecation release note doesn't say that, but the warning in the log does 14:22:51 and as usual, its not removed yet :D 14:22:53 who was the dumbass who wrote that release note 14:23:08 actually, i blame the reviewers 14:23:17 rosmaita: was it me or you? 14:23:22 it was me 14:23:25 :P 14:23:36 but you +2d it! 14:24:27 i'm pretty sure we took an operator survey about it, so there was definitely notice that we did not plan a DB migration 14:24:53 lbragstad, thank you, that will be much helpful 14:25:17 jokke: we were definitely planning to remove 14:25:24 cause if we do not remove that and stop supporting user owned images, the reader will become even more difficult 14:25:25 i think we should do it now 14:25:29 abhishekk if i don't followup with you later today - i'll make a note to sync up with glance early next week 14:25:41 lbragstad, great 14:25:42 jokke: ++ 14:26:04 abhishekk: i suggest prioritizing removing owner_is_tenant 14:26:06 some one should put a patch to remove it 14:26:13 Steap: ^^ how are you set on time? 14:26:19 rosmaita, ack 14:26:37 or not difficult per se, we just can't do project reader and grand read access to all project members as that would be quite horrific security violation 14:26:54 no, we don't want to mess with it at all 14:27:01 let's remove it and not worry 14:27:07 +1 14:29:17 rosmaita: abhishekk: just note on the removal. Specially as there is no migration path we need to make sure we don't accept user as owner after that config option is removed and basically render all images still in that state unusable unles the owner is changed 14:29:44 rosmaita: I'm not sure I understand what you're asking 14:30:19 jokke, ack 14:30:32 Steap: I think he means, "Want to take nice lil upstream task on?" very easy and simple, you just gotta remove one config option :P 14:30:50 Steap: i am asking you to do the work for https://review.opendev.org/#/c/550096/2/specs/rocky/approved/glance/spec-lite-deprecate-owner_is_tenant.rst 14:31:09 it's probably checked like 500 places in the code, though 14:31:36 haha 14:31:37 (did i say that out loud?) 14:31:42 ok I'll take a look at it 14:31:46 (have I doomed myself?) 14:32:10 it shouldn't be too bad code-wise, there will be a lot of tests to remove/refactor, i suspect 14:32:40 Steap, I will be around 14:33:07 $ git grep owner_is_tenant |wc -l 14:33:07 21 14:33:11 seems < 500 14:33:22 not too bad then 14:33:25 awesome, all the best :D 14:33:32 cool, i look forward to seeing your patch tomorrow 14:33:55 that's it for today 14:34:02 Moving to open discussion 14:34:08 rosmaita: sure thing, boss 14:34:08 #topic Open discussion 14:34:19 anything else ?? 14:34:29 yes 14:34:57 #link https://review.opendev.org/#/c/762498/ Stable backport question 14:35:25 We'd like to have this downstream in OSP 16 and least work would be if we can backport it to Train 14:35:48 Yes 14:35:54 Question is, how is the new backport rules with all the old stable branches around etc. Can we actually do it? 14:36:32 IMO we can backport upto two stable branches 14:36:53 as this was done in victoria we can backport it upto Train 14:37:13 i think you can backport it as far as you want 14:37:56 small change, low risk, only affects one glance_store driver 14:38:13 +1 14:38:15 plus, Sean already +2d the ussuri backport 14:39:03 that means you can +2 it :D 14:39:11 Cool, I thought it should be fine, but wanted to make sure 14:39:36 cool 14:39:42 and makes Steap's life lot easier if we get it all the way to train :P 14:39:53 :D 14:40:57 jokke: you can also not open a downstream bug :) 14:41:38 anything else, before closing 14:41:44 but that's all from me 14:41:48 yeah 14:41:54 apart from lets get that done :P 14:42:00 :P 14:42:15 Steap, anything else? 14:43:15 abhishekk do you mind if i update the topic on your patch to secure-rbac? 14:43:24 lbragstad, no problem 14:43:48 thank you all 14:43:59 see you next week, have a nice weekend 14:44:03 thanks everyone 14:44:19 bye! 14:44:25 #endmeeting