14:00:52 <jokke_> #startmeeting glance
14:00:52 <openstack> Meeting started Thu Apr 12 14:00:52 2018 UTC and is due to finish in 60 minutes.  The chair is jokke_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:56 <openstack> The meeting name has been set to 'glance'
14:00:58 <jokke_> #topic roll-call
14:01:01 <jokke_> o/
14:01:06 <rosmaita> o/
14:01:07 <abhishekk> o/
14:01:09 <smcginnis> \o
14:01:35 <McClymontS> GM all o/
14:01:39 <McClymontS> or afternoon/evening
14:01:46 <jokke_> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:01:52 <jokke_> there's the agenda link
14:02:22 <jokke_> we might need to timebox today so lets get started as it seems like we have pretty much everyone around
14:02:33 <jokke_> #topic updates
14:02:55 <jokke_> #link https://etherpad.openstack.org/p/YVR-glance-brainstorming
14:03:21 <jokke_> Last minit to throw your ideas to the Vancouver Summit Forum
14:03:35 <jokke_> last minute even
14:04:09 <jokke_> Who has participation confirmed by now?
14:04:19 <McClymontS> I am booked and will be there
14:04:22 <rosmaita> me too
14:04:27 <jokke_> cool
14:04:33 <jokke_> same here
14:04:36 <abhishekk> I will miss this time
14:04:55 <jokke_> abhishekk: ok :(
14:05:01 <rosmaita> oh yeah, i got an email yesterday about glance onboarding, apparently i am booked for that session -- i will reuse our sydney stuff
14:05:02 <jokke_> I assume smcginnis will be there?
14:05:04 <smcginnis> I will be there.
14:05:13 <smcginnis> But the usual running around. :/
14:05:19 <jokke_> sure
14:05:51 <jokke_> lets try to meet up at some point, if nothing else for some food and pints
14:05:59 <smcginnis> Definitely!
14:06:04 <jokke_> there's good beer and good coffee in Vancouver ;)
14:06:33 <smcginnis> Last time was great. I'm looking forward to exploring Vancouver some more.
14:07:14 <jokke_> then another update which I let rosmaita go more into details is that now when we finally have the glanceclient stable release out, we need to start focusing on 2 things.
14:07:28 <jokke_> removal of the v1 api
14:07:50 <jokke_> if not complete ocde removal, but getting rid of the tests and killing the endpoints
14:08:07 <jokke_> and figuring out how badly intelocked the code is
14:08:44 <jokke_> and the second part is that we have few specs sitting in the review queue that needs attention.
14:08:53 <McClymontS> huge +1 on removal of v1
14:09:02 <smcginnis> For the API, do we have a config option to enable/disable that API?
14:09:12 <jokke_> So lets try to get the feedback into the spec patches and merge the ones we want to have in
14:09:25 <jokke_> smcginnis: yes, those needs to go as well
14:09:46 <smcginnis> jokke_: Checking now, but do we have it defaulted to disabled right now?
14:09:57 <jokke_> smcginnis: and that config option has been false by default of quite a few releases already
14:10:12 <jokke_> for quite
14:10:13 <smcginnis> OK, perfect. Shouldn't be any surprises then.
14:10:30 <rosmaita> yeah, and devstack default is no v1
14:10:34 <McClymontS> Yeah confirmed there its defaulted out
14:10:38 <rosmaita> for a few cycles
14:10:38 <McClymontS> I checked yesterday actually
14:10:49 <smcginnis> rm -fr api/v1 then. :)
14:11:09 <jokke_> smcginnis: I have that patch up already, zuul did not like it ;)
14:11:34 <rosmaita> yeah, my 2 cents from doing the glare-ectomy is that this will take longer than we expect
14:11:46 <McClymontS> It is entrenched in a few places
14:11:57 <McClymontS> Multihash presented those issues as well
14:12:36 <jokke_> rosmaita: thus I'm saying we need to ensure that we get rid of the endpoints and possibilities to enable it in this cycle. Obviously as much of the cleanup as possible
14:12:47 <rosmaita> ++
14:12:59 <smcginnis> Sounds like a good plan to me.
14:13:11 <McClymontS> When does this release cycle end
14:13:17 <jokke_> but we should not - vote those patches just because the patch did not remove all of it
14:13:28 <jokke_> lets just get the work rolling ;)
14:13:50 <smcginnis> McClymontS: Release candidate deadline (code freeze) is the week of Aug 6 - https://releases.openstack.org/rocky/schedule.html
14:13:51 <jokke_> the release is in August IIRC
14:14:28 <rosmaita> #link http://specs.openstack.org/openstack/glance-specs/priorities/rocky-priorities.html
14:14:30 <McClymontS> Awesome thanks smcginnis
14:14:45 <McClymontS> Provides a good amount of time to tackle that
14:14:47 <smcginnis> Would be great to get the v1 endpoint removed earlier in the cycle though, just in case there are any surprises.
14:14:56 <rosmaita> ++
14:15:13 <jokke_> smcginnis: YES! That's why it was prioritized to the very beginning of the cycle
14:15:39 <jokke_> ok, next one
14:15:47 <jokke_> #topic release updates
14:15:52 <jokke_> rosmaita: stage is yours
14:15:52 <rosmaita> i'll make it fast
14:16:09 <rosmaita> we have 2 client releases, one on stable/queens for packagers and one from master
14:16:18 <rosmaita> 2.10.0 and 2.11.0 respectively
14:16:24 <rosmaita> basically the same content in both
14:16:43 <rosmaita> we should be releasing a new stable/queens today
14:17:05 <rosmaita> and we have rocky-1 milestone next week
14:17:06 <jokke_> that's from openstack/glance not client, right
14:17:16 <rosmaita> right, sorry, today will be glance
14:17:31 <rosmaita> rocky-1 milestone aiming for wednesday release
14:17:52 <rosmaita> and our first bug smash is next friday 20 April, so put it on your calendars
14:18:04 <rosmaita> and bug squad meeting monday at some ungodly hour
14:18:10 <rosmaita> this monday
14:18:14 <McClymontS> time edt?
14:18:15 <jokke_> :D
14:18:22 <rosmaita> 6 am
14:18:29 <McClymontS> YEah
14:18:31 <rosmaita> that's all
14:18:33 <McClymontS> lol
14:18:58 <jokke_> #topic uncapping eventlet
14:19:04 <rosmaita> just for info
14:19:05 <jokke_> this should be fast as that's done
14:19:20 <rosmaita> yeah, have we merged those patches?
14:19:41 <jokke_> I think I saw at least the glance merge message in irc
14:19:48 <jokke_> not sure if store was merged yet
14:20:00 <rosmaita> ok, then if glance is ok, should not be a problem
14:20:08 <jokke_> nope, I have my +2 there as of now
14:20:11 <rosmaita> i was worried over nothing, forget about it
14:20:21 <rosmaita> that's all
14:20:54 <jokke_> #topic what to do about store_capabilities_update_min_interval ?
14:21:04 <jokke_> keep the mic
14:21:11 <rosmaita> ok, this came up in glance channel earlier this week, at least i thought it did
14:21:21 <rosmaita> problem with nfs mount for filesystem store
14:21:35 <rosmaita> anyway, it made me realize that we never decided what to do about this option
14:21:45 <rosmaita> that no store actually implements
14:22:04 <rosmaita> so, i was wondering is a spec-lite ok?
14:22:18 <rosmaita> and i think we can deprecate it AND remove the code at the same time
14:22:19 <jokke_> I'm still standing behind the proposal that we should deprecate the config option and remove it next cycle
14:22:24 <rosmaita> since the option does nothing
14:22:30 <rosmaita> and the code is just a stub
14:22:50 <rosmaita> so the deprecation will just be an announcement that you shouldn't expect this to work and it never has
14:22:57 <rosmaita> comments?
14:23:34 <rosmaita> to be clear, spec will be to remove the stub and deprecate the option now, remove the option in S
14:23:48 <jokke_> there is no reason not to follow the standard and leave the removal for next cycle ... just in the case that someone has actually implemented driver or that feature to some of the drivers downstream
14:24:14 <rosmaita> well, its just that you get that really misleading log message that freaks people out
14:24:42 <jokke_> which one?
14:25:05 <rosmaita> i don't remember, it's in the meeting logs from the previous discussion
14:25:17 <rosmaita> it makes it sound like you don't have your store configured properly
14:25:37 <rosmaita> but enough of that ... i will propose a spec lite to deprecate the option
14:25:42 <jokke_> but that's only if you actally configure that
14:25:45 <rosmaita> that's all
14:25:45 <jokke_> ?
14:25:54 <rosmaita> no, you get it no matter what, i think
14:26:04 <rosmaita> anyway, not worth discussing now
14:26:20 <jokke_> oh crap ... ok lets put spec lite up for it and we can nail the details down there
14:26:24 <rosmaita> will do
14:26:28 <McClymontS> yeah spec-lite sounds good
14:26:46 <jokke_> #topic Deleting image data after signature verification failure
14:27:05 <jokke_> #link https://review.openstack.org/#/c/529083/
14:27:13 <rosmaita> that's green, but pretty sure it wasn't me
14:27:19 <jokke_> spoiler alert, I -2'd that approach
14:28:05 <rosmaita> i don't know if it's possible to move the verifier.verify into the store? so we can not store the data when it fails?
14:28:16 <abhishekk> lost the network :(
14:28:20 <jokke_> no point
14:28:58 <jokke_> we would need to cache the data locally and that opens yet another can of worms
14:29:13 <McClymontS> No cahcing
14:29:15 <McClymontS> caching*
14:29:33 <rosmaita> not sure i follow, isn't that how the checksum failure is handled?
14:30:08 <jokke_> rosmaita: the crypto function is fed from the stream when we push the data to the backend
14:30:38 <jokke_> and once that finishes we know if the sig matches or not
14:31:32 <rosmaita> right, but don't we have a feature where you can specify the checksum on image creation, and if the data doesn't match, image is killed?
14:31:50 <jokke_> what actually is the problem here is that we have except statement for that crypto to fail, but we do not handle the data cleanup in the backend before we raise it further
14:31:58 <McClymontS> yes that is true rosmaita I believe
14:32:08 <McClymontS> So jokke_ you think just handle it right there?
14:32:10 <McClymontS> in that exception
14:33:21 <jokke_> McClymontS: yes, when we get the crypto failure, we catch that, remove the data from the backend and after that we raise it back to the api that takes care of killing the image record
14:34:18 <rosmaita> i'm just saying that the store has the verifier, it is passed in, so maybe call verify on it in the store and just delete the data there
14:34:59 <rosmaita> whatever we do, we should try to use the same pattern as the checksum code
14:35:18 <McClymontS> I'm conflicted I agree with both tbh..
14:35:34 <jokke_> rosmaita: that's too late already, the verifier object is passed to the store from the location.py
14:35:58 <jokke_> also IIRC we do not support setting the checksum in v2
14:36:33 <jokke_> which means that from Rocky we also never kill image for checksum failure, only for signature failure if it's signed image
14:38:10 <rosmaita> what behavior do we want here? do we want it to go 'killed' or 'queued' ?
14:38:44 <jokke_> Well it's in released API that it goes killed. I really don't see backwards compatible way to change that
14:39:03 <rosmaita> yeah, but we can say that's v1 only
14:39:25 <jokke_> no image signinghas never been a thing in v1
14:39:36 <rosmaita> i mean the image going killed
14:39:56 <jokke_> but it's not because image signing has been doing that since mitaka or so
14:40:05 <jokke_> that's my point, we fucked it up
14:40:14 <jokke_> and I don't see way out of it
14:40:19 <rosmaita> ok
14:41:05 <rosmaita> well, 'killed' shows up in the image schema, which was kind of a suprise to me this week
14:41:08 <jokke_> it just looks like our datapath is reliable enough that the signature failures does not happen and the fact that there is data left behind is noticed only now ;)
14:44:00 <jokke_> So what I'm saying is, it's a nasty bug and we need to fix it. Lets do it in a right place and not overengineer it to the point where someone in 2-3 years time when we all might be doing something totally different is cursing us to the deepest hell "What were these guys thinking of!" ;)
14:44:32 <rosmaita> hard to disagree with that
14:44:38 <McClymontS> yeah lol
14:45:00 <jokke_> ok next topic
14:45:00 <McClymontS> Leave a comment saying '#my bad'
14:45:11 <jokke_> #topic Images API v1 removal
14:45:20 <jokke_> we did touch this pretty well already
14:45:46 <jokke_> #agreed we need to remove the endpoints in Rocky cycle and do as much code cleanup as possible
14:46:16 <jokke_> I have patch up that removes the v1 tests and last time it ran it's passing the gate
14:46:23 <abhishekk> I can have a look as well
14:46:35 <McClymontS> This will also help from a security perspective
14:46:37 <jokke_> that's a good place to start with to avoid unnecessary failures
14:47:22 <jokke_> #link https://review.openstack.org/#/c/549732
14:47:26 <McClymontS> Specifically this would resolve OSSN-0078
14:47:31 <McClymontS> AFAIK
14:48:14 <rosmaita> McClymontS you are correct
14:48:38 <McClymontS> Along with lessening 76 technically
14:48:41 <jokke_> And please feel free to path up any other tests you might find that still pokes the v1 api
14:49:03 <jokke_> we unfortunately have quite a few of those
14:49:27 <jokke_> That's kind of all from me about this topic. Anyone else?
14:50:06 <jokke_> going once
14:50:20 <jokke_> going twice
14:50:27 <rosmaita> wait
14:50:40 <rosmaita> we need to get this in also: https://review.openstack.org/#/c/553641/
14:50:52 <rosmaita> or the glanceclient gates will start failing when v2 goes
14:51:11 <rosmaita> some core who is not me or abhishekk needs to +A it
14:51:23 <jokke_> #link  https://review.openstack.org/#/c/553641/
14:51:29 <rosmaita> (and i meant v1)
14:52:07 <jokke_> good, thanks for the pointer ... like said that was not on the priority list for client to get the 2.10.0 and 2.11.0 out, now it becomes to that ;)
14:52:23 <rosmaita> ok
14:52:54 <jokke_> I assume that needs to be backported as well?
14:52:59 <rosmaita> nope
14:53:26 <jokke_> or is the stable/queens hitting only stable/queens and no grenada nastyness there?
14:53:29 <rosmaita> stable/queens client tests run in stable/queens devstack
14:53:36 <rosmaita> so should be no problem
14:53:42 <jokke_> ok cool
14:53:48 <jokke_> happy to hear
14:53:50 * rosmaita hopes he is right
14:53:57 <jokke_> next topic!
14:54:19 <jokke_> #topic Restore v1 api-ref?
14:54:26 <rosmaita> Sam Betts filed this bug:
14:54:32 <rosmaita> #link https://bugs.launchpad.net/glance/+bug/1762387
14:54:32 <openstack> Launchpad bug 1762387 in Glance "v1 Image Service APIs in Image Service API Reference" [High,Triaged]
14:54:34 <jokke_> #link https://bugs.launchpad.net/glance/+bug/1762387
14:54:39 <rosmaita> :)
14:54:39 <jokke_> ahh
14:54:42 <jokke_> #undo
14:54:42 <openstack> Removing item from minutes: #link https://bugs.launchpad.net/glance/+bug/1762387
14:55:06 <rosmaita> so the problem is that we got rid of the v1 api-ref to show we are serious about removing v1
14:55:07 <smcginnis> FWIW, we kept Cinder v1 api-ref around for a bit, then decided we didn't want to have that old information out there in the current documentation.
14:55:24 <jokke_> that's kind of my view
14:55:31 <rosmaita> but sam points out that there's no published non-master api-ref
14:55:45 <rosmaita> so i think we need to revert the removal
14:55:49 <smcginnis> How long as v1 been deprecated now?
14:55:56 <jokke_> the info is available in tree for those who wants to refer to the old deprecated/removed stuff
14:55:59 <jokke_> years
14:56:09 <rosmaita> yes, but it has not actually been removed yet
14:56:40 <smcginnis> I could go either way. We could revert it, then remove again once everything is actually removed.
14:56:42 <McClymontS> if v1 still exists I think the docs should
14:56:43 <rosmaita> well, we could just put a note on the api-ref telling you to build it yourself
14:56:47 <McClymontS> I agree with smcginnis there
14:56:48 <jokke_> true, but it has also been disabled by default for years already (at least over year if not 2 year mark yet)
14:56:54 <rosmaita> but it would be better to have the ref there
14:57:09 <rosmaita> we could put up a scary page saying it only applies to really old openstacks
14:57:20 <rosmaita> which are the majority of clouds, tbh
14:57:31 <smcginnis> As long as it's very clearly marked deprecated in the api-ref, not much harm still publishing it for a release or two I suppose.
14:57:44 <jokke_> this is again one of these things I really hate about how we do things ;)
14:58:18 <rosmaita> poor PTL leadership pre-rocky
14:58:23 <McClymontS> lol
14:58:24 <jokke_> "We do not provide certain information from stable branches but we assume it will be always accurate and available from master"
14:58:43 <rosmaita> yeah, openstack is a bit inconsistent about that
14:58:46 <jokke_> rosmaita: this is more OpenStack issue than Glance issue tbh
14:58:55 <rosmaita> i was just being a wise-ass
14:59:27 <rosmaita> so, should i put up a restore patch with scary front page?
14:59:30 <jokke_> so if it's really important to have the API ref for v1 published, go and publish it from the branch it's released from ;)
14:59:41 <jokke_> rosmaita: nah, I do not want that back
14:59:57 <rosmaita> ok, then a note about generating it yourself?
15:00:06 <jokke_> that we can do
15:00:17 <rosmaita> ok, i'll slap something together
15:00:29 <jokke_> and sorry, Open Discussion is today in #openstack-glance as we're out of time!
15:00:30 <smcginnis> Timecheck
15:00:35 <jokke_> Thanks everyone
15:00:39 <rosmaita> bye!
15:00:39 <smcginnis> Thanks!
15:00:40 <jokke_> #endmeeting