14:00:26 <abhishekk> #startmeeting glance
14:00:27 <openstack> Meeting started Thu Mar 26 14:00:26 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:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:30 <openstack> The meeting name has been set to 'glance'
14:00:31 <abhishekk> #topic roll call
14:00:41 <smcginnis> o/
14:00:44 <abhishekk> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:00:47 <abhishekk> o/
14:00:57 <rosmaita> o/
14:01:16 <abhishekk> looks like everyone is here today
14:01:36 <abhishekk> lets start
14:01:54 <abhishekk> #topic Updates
14:02:43 <abhishekk> PTL nominations for Victoria cycle has started from today, and the last day for the nomination is 31st March
14:03:15 <abhishekk> Interested members can submit there nominations within above time frame
14:03:36 <abhishekk> With all your support, I am going to nominate myself again for this cycle
14:03:53 <rosmaita> \o/
14:04:06 <abhishekk> :D
14:04:16 <abhishekk> moving ahead
14:04:31 <abhishekk> 2nd update is we will be having Virtual PTG this time
14:04:47 <abhishekk> kindly go through the discussion regarding the same
14:04:58 <abhishekk> #link http://lists.openstack.org/pipermail/foundation/2020-March/002854.html
14:05:25 <jokke_> o/
14:05:27 <abhishekk> I have created a planning etherpad for glance, you can add your topics in this etherpad
14:05:37 <abhishekk> #link https://etherpad.openstack.org/p/Glance-Victoria-PTG-planning
14:05:53 <abhishekk> I will publish this etherpad through mail as well
14:06:22 <abhishekk> Next week, or later we will discuss possible times and possible mode of meeting for this virtual meeting
14:06:50 <abhishekk> any questions?
14:07:08 <abhishekk> jokke_, o/
14:07:25 <abhishekk> cool, moving ahead
14:07:29 <abhishekk> #topic release/periodic jobs update
14:07:41 <abhishekk> Final release for non-client libraries - 2 weeks away
14:08:00 <abhishekk> For glance-store we need to get s3 support patch in before this
14:08:04 <rosmaita> actually, i think it's next week?
14:08:05 <abhishekk> the patch is in good shape
14:08:19 <abhishekk> let me recheck
14:08:41 <abhishekk> yep, next week
14:09:00 <rosmaita> ok, so even more critical to get that reviewed
14:09:07 <smcginnis> Yeah, getting close to the end of cycle crunch.
14:09:22 <rosmaita> abhishekk and jokke_ how are you set for time?
14:09:34 <abhishekk> that patch has one +2 already from jokke_
14:09:42 <rosmaita> i can take a quick look, but not sure i can do a thorough review
14:09:59 <rosmaita> ok, that's good
14:10:02 <jokke_> yup, did couple of circles around it and I thing it's fine for now
14:10:14 <rosmaita> great
14:10:19 <abhishekk> I am also through for the patch
14:10:34 <smcginnis> A couple follow up items, but nothing I thought was too critical.
14:10:56 <abhishekk> From client perspective we are good and everything important is merged
14:11:19 <jokke_> smcginnis: indeed, I was perfectly fine him following up with the couple of small things due to the time constrains ... the behaviour is ok
14:11:34 <abhishekk> +1
14:11:58 <abhishekk> I will propose release notes patches for both store and client tomorrow
14:12:11 <abhishekk> and then will propose release patch on monday morning
14:12:21 <smcginnis> ++
14:12:33 <abhishekk> great
14:12:36 <jokke_> and the client deadline is not just yet, so if there is anything needed, we still have bit time with that
14:13:14 <abhishekk> yes
14:13:32 <smcginnis> Are there any feature changes we've merged on the service side that we need to make sure are in the client? Single store delete?
14:13:49 <abhishekk> smcginnis, that is already in
14:13:50 <jokke_> smcginnis: iirc that merged already in client
14:13:58 <jokke_> we should be all up to date as of now
14:14:04 <smcginnis> Perfect!
14:14:10 <abhishekk> we don't have anything for the client at the moment
14:14:39 <jokke_> the s3 store does not need anything form client side, nor does the decompression plugin
14:14:42 <abhishekk> Regarding periodic jobs, couple of timeouts
14:14:58 <abhishekk> but no subunit parser errors since last two weeks
14:15:22 <abhishekk> I will monitor the logs for timeouts later today
14:15:27 <jokke_> abhishekk: that sounds very good at this point of the cycle, so definite improvements with that subunitparser update
14:15:42 <rosmaita> very nice
14:15:45 <abhishekk> jokke_, yes, it is
14:16:08 <abhishekk> The original bug is closed now, I will mark it closed for glance as well
14:16:22 <jokke_> ++
14:16:23 <smcginnis> Glad that has at least improved.
14:16:31 <abhishekk> ++
14:16:48 <abhishekk> moving ahead, rosmaita you are next
14:16:53 <abhishekk> #topic deprecate admin_role
14:17:19 <rosmaita> yeah, so a question came up in the openstack questions thing
14:17:28 <rosmaita> #link https://answers.launchpad.net/glance/+question/689450
14:17:43 <rosmaita> that person was having trouble configuring a policy file
14:17:59 <rosmaita> turns out they were unaware of the sneaky glance admin_role option
14:18:20 <rosmaita> i think that's a holdover from pre-policy days in bexar
14:18:26 <rosmaita> and we should get rid of it
14:18:33 <rosmaita> #link https://review.opendev.org/714626
14:18:42 <rosmaita> so i put up a spec lite to deprecate it
14:18:55 <rosmaita> this way, all policy config will be done in one place
14:19:15 <rosmaita> there's an alternative on the spec-lite if we don't want to remove it
14:19:23 <rosmaita> but i think removal is best
14:19:28 <abhishekk> +1
14:19:33 <rosmaita> (i will now pause for comments/questions)
14:20:08 <abhishekk> But I think we should deprecate it now and remove it in next cycle 1st milestone
14:20:29 <rosmaita> yes, that's what i meant by removal
14:20:37 <smcginnis> Sounds good to me.
14:20:47 <jokke_> I'm not exactly convinced we should, knowing how many people refuses to change their ways and how many things in our API needs adminness, I'd prefer either defaulting to None or something in those lines. I do agree that the current default value can be problematic. Although I'd check if tempest has test for any of that because if they do we will just never be able to change that
14:21:17 <abhishekk> ack, you added one line in the last
14:21:52 <rosmaita> well, we could send an email to the ML asking if anyone is aware of that option
14:22:02 <jokke_> So changing the default value to something sensible, if we can would at least avoid us being yet again stuck with deprecated thing we can't get rid of due to QA
14:22:19 <abhishekk> hmm, need to check tempest side
14:22:30 <rosmaita> i doubt they make use of it
14:22:35 <smcginnis> Even if it takes more than one release, it would at least be a good signal to everyone that that is not the preferred way to do things now.
14:22:39 <rosmaita> besides, it matches what's in the default policy config
14:22:49 <rosmaita> so that's why most people don't notice it
14:23:03 <abhishekk> agree with smcginnis
14:24:30 <jokke_> smcginnis: it's not matter of more than one release, QA made very clear that default values can't be changed if they are included in tests (look default image visibility)
14:25:07 <rosmaita> jokke_: it's not exposed in devstack, so there's no way for tempest to use it
14:25:09 <smcginnis> True, but at least eventually we can move away from it once all currently supported releases have had it deprecated.
14:25:54 <jokke_> rosmaita: ok, great, that's hopefull
14:26:12 <abhishekk> I will reconfirm this and add comment on the patch
14:27:00 <jokke_> so can we change that default value away from admin before release to get rid of that confusion now and we can then probe input if anyone is actually using/aware of it for deprecation?
14:27:00 <abhishekk> moving into Open discussion
14:28:01 <jokke_> as in can we do both the deprecation and the alternative approach to speed up addressing the actual issue?
14:28:19 <rosmaita> not sure
14:28:33 <abhishekk> not ideal IMO
14:28:43 <rosmaita> tell you what though
14:28:58 <rosmaita> i can mention that in the deprecation release note
14:29:28 <abhishekk> That could be the good idea
14:29:33 <rosmaita> that you should change it to some weird value and if something breaks, you are depending on it
14:29:35 <abhishekk> s/the/a
14:30:04 <jokke_> maybe a good place to utilize the fancy upgrade test?
14:30:33 <jokke_> to check if that value is actually set and alert we're trying ot get rid of it
14:30:53 <abhishekk> we should avoid this test at the moment I guess, we are just two weeks away from the release :P
14:30:57 <rosmaita> i guess we could, but usually the deprecation note is thought to be sufficient
14:31:25 <abhishekk> +1
14:31:26 <rosmaita> also, what abhishekk said
14:31:50 <rosmaita> i have time to do a quick release note, but not to get the upgrade check done and tested
14:32:03 <rosmaita> because i think all we have right now is the stub?
14:32:33 <abhishekk> and I started hating mocks and stubs since this morning
14:32:41 <rosmaita> :D
14:33:20 <jokke_> :P
14:33:29 <abhishekk> I guess jokke_ agrees to my last statement :D
14:34:05 <jokke_> abhishekk did not believe me how impossible it is to make meaningful unit tests for the decompression plugin before he spent few hours trying :P
14:34:27 <abhishekk> :P
14:35:22 <jokke_> oh btw!!
14:35:24 <abhishekk> In the end I have mocked every function of that decompression class including inbuilt open method and even though that test was giving weird results
14:35:38 <abhishekk> #topic Open discussion
14:35:46 <jokke_> yes this one
14:36:11 <jokke_> so I found something disturbing while testing the decompression plugin
14:36:20 <jokke_> we need to refactor web download
14:36:51 <abhishekk> what it is?
14:37:17 <jokke_> I don't know yet what in there blows and sucks at the same time but if you try to use it in python 3 against https:// url, it will blow up due to enventlet cert thingie
14:37:38 <abhishekk> ohhh
14:37:49 <rosmaita> yuck
14:38:07 <jokke_> so someone (me) has been very stupid when originally designing that plugin and how it actually does the fetch
14:38:09 <abhishekk> Will have a look tomorrow morning first thing
14:39:10 <abhishekk> thanks for the pointer
14:39:31 <jokke_> The other thing, i'm pretty confident that the decompression plugin PS is now ready to go ... we've been going back and forth with abhishekk on that and beating the horse dead frm pretty much every angle. It should be solid
14:39:48 <abhishekk> +1
14:40:08 <abhishekk> I am confident about that now
14:41:08 <abhishekk> I will give another try as a followup for unit test but not much confident above that
14:41:36 <abhishekk> so smcginnis or rosmaita kindly have a look at that patch
14:42:03 <rosmaita> ok
14:42:04 <jokke_> #link https://review.opendev.org/#/c/714113
14:42:12 <smcginnis> Will do
14:42:13 <abhishekk> cool
14:42:16 <rosmaita> thanks
14:42:21 <abhishekk> thank you
14:42:23 <jokke_> thanks
14:42:40 <abhishekk> I have one question, what is the deadline to submit cycle highlights?
14:42:48 <jokke_> and the ps from half an hour ago contains docs and ren for it
14:42:56 <jokke_> reno
14:43:11 <rosmaita> i think april 9
14:43:53 <smcginnis> Yep
14:43:59 <abhishekk> rosmaita, smcginnis ack
14:44:10 <abhishekk> I guess we are good for today
14:44:21 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012873.html
14:44:22 <abhishekk> do we have anything else to discuss?
14:44:25 <rosmaita> actually april 10
14:44:25 <jokke_> nothing from me at least
14:44:33 <abhishekk> rosmaita, thank you
14:44:34 <rosmaita> me neither
14:44:40 <smcginnis> Nothing from me.
14:44:48 <abhishekk> cool, thank you all
14:45:02 <abhishekk> have a nice weekend
14:45:07 <smcginnis> Thanks! You too.
14:45:11 <smcginnis> Stay safe.
14:45:17 <smcginnis> And not too bored.
14:45:27 <abhishekk> yes that's the priority
14:45:34 <abhishekk> we are in 21 days lockdown
14:45:42 <abhishekk> and today is just 2nd day of it
14:46:05 <abhishekk> #endmeeting