14:00:12 <abhishekk> #startmeeting glance
14:00:13 <openstack> Meeting started Thu May 27 14:00:12 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:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:16 <openstack> The meeting name has been set to 'glance'
14:00:21 <abhishekk> #topic roll call
14:00:27 <dansmith> o/
14:00:30 <abhishekk> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:00:33 <abhishekk> o/
14:00:53 <abhishekk> lets wait couple of minutes for others
14:01:15 <Steap> (so, are we moving to the-other-IRC-server any time soon?)
14:01:39 <abhishekk> will come to that in a bit
14:02:13 <jokke> o/
14:02:22 <abhishekk> cool, lets start
14:02:39 <abhishekk> #topic Updates
14:03:19 <abhishekk> Migration of network, So everyone is aware about current decision made by TC
14:03:46 <dansmith> yup
14:03:50 <abhishekk> I would suggest to follow their guidelines and be ready
14:03:58 <dansmith> I have a network-independent suggestion/request
14:04:10 <abhishekk> sure
14:04:27 <abhishekk> got it, moving ahead
14:04:30 <dansmith> once we migrate, can we move this meeting to start happening in the glance channel itself? the meeting bots work the same there and some other projects have started doing that, qa and tc at the least
14:04:37 <rosmaita> o/
14:04:54 <abhishekk> I am ok for this
14:05:05 <abhishekk> would like to know what other thinks about the same
14:05:10 <dansmith> it just means fewer channels open all the time, and/or less having to jump to a meeting channel, and generally less reminding
14:05:24 <dansmith> potentially also more involvement from people that just lurk in the channel but not the meeting channels
14:05:27 <jokke> Considering the amount of complains for people jumping in middle of meeting with off topic questions just because they don't realize meeting being ongoing I'd prefer us to stay on the meeting channel for clarity
14:05:31 <abhishekk> ++
14:05:45 <abhishekk> jokke, Steap, rosmaita any concerns ^^
14:06:14 <jokke> this seems to be one of those reasons people dislike IRC so lets not add fuel to that fire ;)
14:06:26 <Steap> I'm fine either way, as long as we run away from you know where
14:06:41 <abhishekk> Lets see what TC suggests about the same
14:06:42 <dansmith> when I started participating, the meeting channel was listed incorrectly on the wiki too, so I was in the wrong meeting channel for a few minutes wondering where everyone was
14:06:59 <abhishekk> I remember that :D
14:07:02 <dansmith> yeah :D
14:07:29 <dansmith> anyway, not a big deal, but I don't think there's enough traffic in -glance to worry about interruptions
14:07:35 <rosmaita> i prefer using a dedicated meeting channel
14:07:59 <abhishekk> Ok so we have 2 vs 2 + Steap either way
14:08:14 <Steap> is it easier for everyone if I choose a side? :)
14:08:20 <rosmaita> we should weight votes by seniority :)
14:08:27 <abhishekk> yep
14:08:28 <jokke> :P
14:08:31 <abhishekk> :D
14:09:04 <jokke> Maybe we need a bot to relay the meeting channel to the project channel :D
14:09:06 <abhishekk> Ok, I think lets see what TC suggests and then we can decide on this
14:09:17 <abhishekk> :D
14:09:17 <dansmith> if people have a strong preference for status-quo then just stick with that
14:09:29 <abhishekk> ack
14:09:32 <abhishekk> moving ahead
14:09:39 <abhishekk> #release/periodic jobs update
14:09:48 <abhishekk> So this is M1 release week
14:10:03 <abhishekk> we don't have concrete patches merged to tag a release
14:10:25 <abhishekk> So we can skip this M1 release this time
14:10:29 <dansmith> bummer
14:10:52 <jokke> abhishekk: sounds good, first tag on m2
14:11:07 <abhishekk> Yep
14:11:44 <abhishekk> periodic jobs are green this week as well
14:11:46 <jokke> I think m1 is just great reminder at the beginning of every cycle how quickly the start of the cycle disappears
14:12:26 <abhishekk> for to those who have really really less active contributors
14:12:40 <abhishekk> #topic Priority specs
14:12:49 <abhishekk> So we have two specs on priority
14:12:56 <abhishekk> 1. Unified quotas
14:13:16 <abhishekk> which is ready to merge with 2 +2s
14:13:33 <abhishekk> If there are no concerns raised by this week, I will approve the spec
14:13:37 <jokke> dansmith: sorry if I have missed anything ongoing on the quota spec. Will look it after this meeting :(
14:13:51 <abhishekk> 2nd Cache API - Yet working on modification
14:13:58 <dansmith> abhishekk: and if there are, we're punting again?
14:14:33 <abhishekk> If there are any valid concerns which are not addressed already then we need to
14:14:35 <dansmith> abhishekk: I'm waiting until we agree/merge that before I spend more time working on the things we've discussed since, and we're getting to the point where it's been mostly sitting
14:15:05 <abhishekk> I understand, I need to follow some protocols
14:15:33 <abhishekk> I know how it feels when work is sitting without any attention
14:15:42 <abhishekk> and I am sorry for that
14:15:58 <abhishekk> We need to improve on providing reviews
14:16:18 <abhishekk> this will be lesson for us if we want to attract new contributors/ new people
14:16:48 <abhishekk> dansmith, point is noted and will be addressed as well
14:16:57 <dansmith> thanks, hope so
14:17:05 <abhishekk> Yes
14:17:17 <dansmith> I'm happy to address things, but 1.5 weeks between revisions is pretty painful
14:17:31 <abhishekk> understood
14:17:39 <dansmith> on the cache thing, I haven't seen a spec update yet, did I miss it?
14:18:05 <abhishekk> nope, we didn't put up a modified spec yet
14:18:32 <abhishekk> jokke, I guess we need to work on modification of spec
14:18:52 <jokke> ++
14:18:58 <abhishekk> Expect a modifies spec before next weekly meeting
14:19:11 <abhishekk> Moving ahead
14:19:16 <abhishekk> #topic
14:19:21 <abhishekk> #topic Policy refactoring
14:19:47 <abhishekk> I guess, me and rosmaita both have reviewed the work
14:20:07 <abhishekk> and the approach sounds promising to me
14:20:11 <dansmith> abhishekk: I haven't seen a review from you
14:20:25 <abhishekk> I didn't put a comment there?
14:20:31 <dansmith> does that mean you looked at it and are happy with the approach?
14:20:32 <dansmith> not that I saw
14:20:43 <dansmith> I saw some comments on the earlier patches,
14:20:43 <abhishekk> yes
14:21:01 <abhishekk> I think I forget to post it, must be in my drafts
14:21:06 <dansmith> but the last one is the actual poc we need to decide on
14:21:08 <dansmith> okay
14:21:46 <abhishekk> So apart from finding reason for Conflict and Forbidden everything else seems inline to me
14:21:57 <abhishekk> I am still not able to find the reason for this
14:22:17 <dansmith> I looked a bunch early on, but figured you guys would be able to spot it easily,
14:22:21 <abhishekk> and on top of that why tests are not failing after changing to Forbidden to conflicts as well
14:22:21 <dansmith> and I haven't tried since
14:22:32 <dansmith> but if rosmaita and abhishekk can't figure it out, I doubt I can
14:22:53 <rosmaita> i was thinking it may have to do with the amount of crap you can put in a PATCH request
14:22:58 <abhishekk> I will try to configure property protection and manually test the scenario
14:23:12 <rosmaita> some stuff might get kicked out before it hits the current policy layer of the onion
14:23:13 <dansmith> rosmaita: right, like they were failing due to some other conflict and not the actual property protection right?
14:23:19 <rosmaita> exactly
14:23:33 <dansmith> rosmaita: that's what I was saying -- the tests were just asserting what the test-writer was experiencing instead of what they should be
14:23:35 <abhishekk> Then what has changed now
14:24:07 <dansmith> and that's one reason putting the policy stuff up a layer is good because rejecting on policy before we get into other semantics is good
14:24:13 <dansmith> i.e. instead of waiting until the DB layer
14:24:23 <abhishekk> +1
14:24:37 <abhishekk> I think, we should start working on spec for this
14:24:48 <rosmaita> agree, but still have abhishekk's question about why the tests pass either way
14:25:11 <dansmith> I'm not sure I understand "either way"
14:25:52 <abhishekk> means in your patch you just changed tests from conflict to forbidden, then why they are passing now
14:26:07 <abhishekk> and even passed the patch before that
14:26:51 <dansmith> because of the roles change
14:26:58 <jokke> which patch you are talking about?
14:27:00 <dansmith> they weren't passing roles before
14:27:08 <abhishekk> ah
14:27:13 <dansmith> er, they weren't passing the member role
14:27:19 <dansmith> and that's what the policy rules check
14:27:24 <abhishekk> jokke, give me a minute
14:28:08 <abhishekk> https://review.opendev.org/c/openstack/glance/+/789914
14:28:31 <abhishekk> dansmith, right, that could be the case
14:28:53 <dansmith> the tests are still running with unrestricted base policy until the last patch
14:29:25 <dansmith> so they don't check any of the regular policy stuff, only the protections since they don't pass the member role
14:29:59 <abhishekk> hmm and due to protection stuff it could have been raising 403 conflict there
14:30:15 <dansmith> unfortunately it's been almost a month since I looked at this, so I'll have to load it all in my head again
14:30:24 <abhishekk> Ok, I will try to manual test property protection for that particular scenario
14:30:26 <abhishekk> :/
14:30:50 <abhishekk> ok, moving ahead
14:31:20 <abhishekk> #topic Bi-weekly Bug discussion (2nd)
14:31:37 <abhishekk> Today we are going to discuss bugs from glance-store
14:31:55 <abhishekk> our regular tracking etherpad is, https://etherpad.opendev.org/p/glance-bug-tracker
14:32:16 <abhishekk> Lots of bugs are waiting there to Close, which me and Steap will do soon
14:32:24 <abhishekk> Lets talk about the 1st bug
14:32:38 <abhishekk> #link https://bugs.launchpad.net/glance-store/+bug/1675950
14:32:39 <openstack> Launchpad bug 1675950 in glance_store "swift auth opts to be removed from glance store code" [High,Triaged]
14:32:52 <abhishekk> this bug is reported in 2015 for swift driver of glance
14:33:21 <abhishekk> and last comment is from rosmaita on this
14:33:21 <Steap> I'm not sure why it's high, but it makes sense to remove options that have been deprecated for 6 years+
14:33:34 <abhishekk> since then there is no work done on this
14:34:17 <abhishekk> I think jokke has worked recently on swift driver of glance, so he could help us on this
14:34:33 <jokke> kk
14:34:53 <jokke> yeah that has not been exactly the priority of my investigations, but makes sense
14:35:09 <abhishekk> The action could be see whether these options are used anywhere in swift driver
14:35:19 <rosmaita> not sure why i made that High, but that was 3 years ago
14:35:25 <abhishekk> if yes find the alternative and remove those options
14:35:32 <rosmaita> guess i really wanted to get it into rocky
14:36:14 <jokke> rosmaita: :D
14:36:31 <abhishekk> rosmaita, I think that was the reason, I remembered but unfortunately Dharini disappeared and that remain un-addressed
14:37:15 <abhishekk> next one
14:37:18 <abhishekk> #link https://bugs.launchpad.net/glance-store/+bug/1904546
14:37:19 <openstack> Launchpad bug 1904546 in glance_store "Multiattach with Image volume backed" [High,New]
14:37:50 <abhishekk> As recently commented by dansmith we do have a spec and patch for this
14:38:13 <abhishekk> but it is sitting identical since proposed due to lack of reviews
14:38:16 <dansmith> and my +2 is on it, but no attention from anyone else
14:38:51 <abhishekk> This is another example where everyone of us (old team) need to priorities our reviews each week
14:39:27 <abhishekk> I will ask the owner to include this bug reference either in spec or patch
14:39:32 <abhishekk> next one
14:39:51 <abhishekk> #link https://bugs.launchpad.net/glance-store/+bug/1185851
14:39:53 <openstack> Launchpad bug 1185851 in glance_store "glance allows delete even if cannot be deleted from ceph backend store" [Medium,In progress] - Assigned to Edward Hope-Morley (hopem)
14:40:27 <abhishekk> This was reported in 2013
14:40:47 <abhishekk> We need to identify that this scenario/issue still exists
14:41:05 <jokke> I'm pretty sure that has not been the case ofr the long time. Was that verified still being the issue?
14:41:11 <jokke> -the
14:41:34 <abhishekk> If yes then provide a fix
14:42:06 <abhishekk> Yes, I think that is in progress and the work is abandoned, so we need to verify that it is still a valid case of now
14:42:24 <abhishekk> We do catch InUse exception in RBD driver
14:43:11 <abhishekk> Me and Steap will look into this issue and provide update on the bug
14:43:41 <jokke> yeah, I'm pretty sure that bug has been fixed for ages, and it just needs housekeeping
14:43:49 <jokke> as in to be closed as fixed
14:44:17 <abhishekk> cool, we will confirm the same and update it with appropriate comment
14:44:40 <abhishekk> That's it from me, moving to open discussion
14:44:46 <abhishekk> #topic Open discussion
14:45:53 <abhishekk> I would like to suggest we should start following certain deadline apart from milestones for our work
14:46:15 <abhishekk> This will help us to get timely attention to work done by each of us
14:46:56 <jokke> dansmith: rotating bit back to the quotas spec, I think you addressed every one of my comments there and it seems that everyone else is fond of the easy way of soft quotas. I'll read it through once more with focus but not assuming there being anything else from me left
14:47:13 <dansmith> jokke: thanks
14:47:28 <dansmith> abhishekk: can you provide an example of what you're suggesting?
14:47:31 <abhishekk> Or we should assign particular reviewers to certain feature work/priority bugs
14:48:01 <abhishekk> So at the start of the cycle we know what feature we are going to target this cycle
14:48:12 <abhishekk> we also know who will own that work
14:48:50 <abhishekk> so depending on the amount of work we should put a internal deadline for spec, actual work, that we should expect to be merged
14:49:23 <abhishekk> also we should volunteer particular reviewer to that work
14:50:11 <abhishekk> we can keep rosmaita  on standby
14:50:29 <dansmith> I guess it seems to me like we don't have enough reviewers or review bandwidth to really separate duties
14:50:43 <jokke> dansmith: ++
14:50:51 <dansmith> we've done things like that in nova in the past and it has been fine, but... there are a lot of people doing reviews over there
14:51:07 <abhishekk> that is the case since 3/4 years for now
14:51:31 <jokke> yeah, honestly I just need to block some time off for myself to keep focus on reviews
14:51:33 <dansmith> yeah, I mean.. I like what you're saying, I just am not sure it will work well here because of the number of people
14:51:56 <abhishekk> Why not give it a try?
14:52:23 <jokke> I have way too many review tabs open, I've started and just got distracted by some ping and forgotten to get back to
14:52:35 <dansmith> abhishekk: I'm all for trying anything, so I'm not trying to say no to anything :)
14:52:46 <abhishekk> Next meeting we could decide work and volunteer and decide deadline
14:52:47 <rosmaita> (sorry, got pulled away, just reading the scrollback now)
14:53:13 <abhishekk> rosmaita, I know you have parallel meeting, so no worries
14:53:37 <abhishekk> I think we should give it a try for 1/2 specs and lets see how it goes
14:53:49 <jokke> abhishekk: I think Dan's point was we're 3 people and even with normal change 2 is needed for merge. Honestly, we just need all to be on ball to not rely rosmaita and smcginnis to find their time on Glance work
14:53:54 <abhishekk> I would like to monitor work for quotas and cache for this
14:54:04 <abhishekk> I am considering Steap for reviews as well
14:54:24 <dansmith> abhishekk: so to be clear,
14:54:26 <abhishekk> I would also request pranali to help us in glance revierws
14:54:49 <dansmith> you're saying pick two cores per spec/effort and we merge when those two are happy instead of waiting for everyone?
14:55:05 <abhishekk> Yes
14:55:28 <dansmith> so, first off, I think waiting for everyone to be on board for everything is a problem, so +2 to that
14:55:42 <abhishekk> also we will have reviews from Steap as well
14:55:56 <dansmith> however, (b) if some person is really slammed one cycle and their sign-off is needed to  merge a thing,  it's unfortunate to limit that thing because of its assignee
14:56:36 <dansmith> but I'm definitely happy to see it drop to "two cores is enough for a spec" regardless of how we get that
14:56:57 <abhishekk> In that case we will do what we have done in last cycle, either we request rosmaita to have look or we go ahead with vote of one core reviewer
14:57:16 <rosmaita> i can usually find time for a look when i am pinged
14:57:26 <abhishekk> ++
14:57:39 <abhishekk> We need to do something to improve
14:57:51 <dansmith> for sure
14:57:58 <abhishekk> I can not sit ideal and let it go as it is
14:57:59 <rosmaita> i think the policy for specs should be two +2s like for normal patches, with the option that the PTL can require more if he/she thinks it's necessary
14:58:12 <abhishekk> yes
14:58:14 <dansmith> I think the turnaround time and velocity is a big problem too, fwiw
14:58:44 <rosmaita> i pushed for the "everyone approve" model, but that's when i was dedicated to glance 100%, probably not practical any more
14:59:09 <dansmith> checkpointing once per week (at the end of the week no less) ends up with a lot of "okay, but for sure by NEXT week" stuff
14:59:13 <dansmith> rosmaita: ++
14:59:34 <jokke> Well it was the turnaround time with specs that initially got us here (at the time when we had plenty of contributors and cores) some specs got merged with that 2x+2 before majority had even time to look into them. Which we are obviously not struggling about anymore
14:59:41 <abhishekk> That is where deadline comes into the picture
14:59:45 <jokke> Just a little glimpse to history there
15:00:13 <abhishekk> TIme is up
15:00:29 <abhishekk> lets switch to openstack glance
15:00:29 <dansmith> abhishekk: +1 for more granular deadlines if that's what you mean
15:00:32 <dansmith> I have to go to another meeting
15:00:35 <abhishekk> thank you all
15:00:45 <abhishekk> #endmeeting