14:00:11 <jokke_> #startmeeting glance
14:00:11 <openstack> Meeting started Thu Jun 21 14:00:11 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:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:15 <openstack> The meeting name has been set to 'glance'
14:00:18 <jokke_> #topic roll-call
14:00:24 <abhishekk> o/
14:00:25 <jokke_> o/
14:00:54 <rosmaita> o/
14:01:06 <smcginnis> o/
14:01:46 <jokke_> ok. I have nothing special for updates, so lets use the meeting time effectively
14:01:51 <jokke_> #topic release updates
14:02:04 <rosmaita> hello
14:02:15 <abhishekk> welcome back
14:02:18 <rosmaita> periodic jobs: all showing green
14:02:20 <rosmaita> thanks!
14:02:31 <rosmaita> just some reminders of upcoming deadlines:
14:02:43 <rosmaita> this week is R-minus-10
14:02:51 <rosmaita> R-minus-6: final glance_store Rocky release (July 18)
14:02:59 <rosmaita> R-minus-5: final glanceclient Rocky release (July 25)
14:03:06 <rosmaita> R-minus-3: RC-1 (August 8)
14:03:28 <rosmaita> those dates are all wednesdays, it usually takes a day to get everything through the final gate
14:03:52 <rosmaita> and, finally, bug squad meeting coming up on monday at 10:00 UTC
14:04:03 <rosmaita> that's all from me
14:04:42 <jokke_> cool
14:04:50 <jokke_> #topic client-side validation
14:04:55 <jokke_> you can continue
14:05:07 <rosmaita> ok
14:05:47 <rosmaita> i noticed a new patch that wants to detect too long tag length in the client and error out without making a call to glance
14:05:54 <rosmaita> https://review.openstack.org/#/c/576458
14:06:12 <rosmaita> this approach was pretty much rejected for making that kind of change in the client code itself:
14:06:19 <rosmaita> https://review.openstack.org/#/c/429518/
14:06:31 <rosmaita> the bug is here: https://bugs.launchpad.net/glance/+bug/1640442
14:06:32 <openstack> Launchpad bug 1640442 in Glance "glance image-tag-update, not updating a tag whose length is more than 255" [Undecided,Confirmed] - Assigned to lihaijing (lihaijing)
14:06:39 <rosmaita> stuart had some good comments about why not to do it
14:07:07 <smcginnis> Would it ever be longer than 255?
14:07:22 <rosmaita> i think it's a db restriction
14:07:30 <rosmaita> but it could be made shorter
14:07:38 <rosmaita> and more to your point, we could change the db
14:07:43 <jokke_> that it is, but because it's schema driven it might be shorter
14:07:43 <rosmaita> (sorry, still in vacation mode)
14:08:20 <rosmaita> yeah, so if the schema changes, we really don't want to be changing a bunch of outdated code
14:08:34 <smcginnis> Just wonder, if it could be less but we never expect it to be more than 255, is there harm in detecting that on the client side and saving a round trip?
14:08:37 <jokke_> this clearly doesn't seem to go through, so how about I'm the evil here and go to -2 both of those and mark the bug back to invalid :P
14:09:11 <jokke_> rosmaita: also it might be operator thing to change the schema and they definitely don't want to be changing hardcoded values
14:09:20 <rosmaita> smcginnis the problem is that we've got 2 different codebases, the schema is the go-between to keep things in sync
14:09:24 <rosmaita> jokke_ that is a good point
14:09:31 <rosmaita> it is do-able, though not encouraged
14:09:34 <jokke_> smcginnis: that is already validated in the client
14:10:10 <rosmaita> yeah, to be clear, this could be fixed by translating the 400 response from the API to something more user-friendly
14:10:20 <rosmaita> i think i said that on one of the patches
14:10:28 <rosmaita> but hard-coding the value is not a good idea
14:10:43 <jokke_> IIRC that 400 is raised by client
14:10:44 <rosmaita> my real point is that we should just close these out if we're not going to accept the patches
14:10:58 <abhishekk> ++
14:11:06 <jokke_> the client at least should validate outgoing requests against the schema
14:11:26 <rosmaita> jokke_ you are most likely correct there
14:11:42 <rosmaita> so we are already saving the trip to the API
14:12:06 <jokke_> yup
14:12:27 <rosmaita> i think if someone wanted to take on the task to make the errors more user-friendly that would be OK, but it's not necessary
14:12:54 <rosmaita> so i vote for jokke_ to be the bad guy and -2 everything and abandon them
14:13:04 <smcginnis> +1
14:13:07 <abhishekk> +1
14:13:36 <jokke_> the original request was to get more user friendly and informational error from client that I encouraged to do and neither of the people who started working on this wanted to do that but instead tried to do some stupid hardcoding into the client
14:14:04 <jokke_> ok, will drop those things
14:14:07 <rosmaita> yeah, the hard coding is easier to implement but a bigger pain to maintain
14:14:21 <jokke_> and it's just in general bad idea
14:14:24 <rosmaita> jokke_ you could repeat what you just said when you invalidate the bug
14:14:38 <jokke_> specially on something thta gets validated against schema
14:15:00 <rosmaita> ++
14:15:21 <rosmaita> ok, that's all i had on that topic
14:15:26 <jokke_> ok
14:15:38 <jokke_> #topic open discussion
14:16:12 <jokke_> so I have been trying to get some sense out of the message queue stuff and getting rid of v1
14:16:52 <jokke_> and we need to review abhishek's multi-store stuff so we can get to an agreement before we need to release the final from glance_store
14:17:18 <abhishekk> I have uploaded patches for multiple backends support, unit tests for glance_store and client are done
14:17:32 <abhishekk> pending is unit tests for glance and functional tests for glance
14:17:36 <rosmaita> abhishekk: good work
14:17:41 <jokke_> so as usual the end of the cycle is approaching quick and we have hell of a lot to do
14:17:47 <abhishekk> thanks :D
14:18:07 <rosmaita> i'll commit to reviewing the glance_store change later today
14:18:14 <abhishekk> I have uploaded documentation patch as well, need eyes on the language :D
14:18:34 <rosmaita> you have been busy!
14:19:02 <abhishekk> rosmaita, tough task is to write meaningful functional tests
14:19:27 <abhishekk> jokke_, as suggested I have mentioned experimental thing in docs
14:19:39 <jokke_> goodie
14:19:55 <jokke_> rosmaita: yes, so I think you were in holidays when we discussed this
14:20:06 <rosmaita> i saw something in the channel logs
14:20:16 <rosmaita> experimental in rocky, stable in stein?
14:20:31 <abhishekk> also on these are some scenarios which I have tested
14:20:31 <jokke_> we agreed to stamp the multi-store EXPERIMENTAL so we can gather feedback and make changes still next cycle if needed
14:20:32 <abhishekk> https://etherpad.openstack.org/p/multi-store-scenarios
14:20:42 <jokke_> rosmaita: correct
14:20:48 <rosmaita> makes sense to me
14:21:00 <jokke_> this should be easy thing to get that feedback
14:21:22 <abhishekk> yeah that was a super idea
14:21:27 <jokke_> as this feature has been requested for so long
14:23:41 <jokke_> If any of you have nothing else, I think we can free 35min today
14:24:04 <jokke_> or all of you
14:24:11 <abhishekk> https://review.openstack.org/#/c/251471/
14:24:28 <abhishekk> oslo.config has a support for mutable config options
14:25:34 <abhishekk> we can see how we can use it in glance
14:26:08 <jokke_> I'd like to say, lets worry about that in Stein if this approach sticks
14:26:26 <abhishekk> sounds good
14:26:32 <rosmaita> yeah, i don't like the "this is the second attempt at implementing this" comment
14:26:34 <smcginnis> The goal for this release is just to support log levels, which I think handles that.
14:26:39 <jokke_> ohh ... rosmaita you guys have any updates about multi-hash?
14:26:44 <rosmaita> nope
14:26:51 <smcginnis> But good follow up for everyone to think about whether there are any other config options that can be changed at runtime.
14:27:19 <jokke_> rosmaita: is that expectation that it will not be ready in Rocky?
14:27:25 <rosmaita> not yet
14:27:32 <jokke_> as IIUC that needs store change as well
14:27:37 <jokke_> so it's bit tighter
14:27:44 <rosmaita> yes, store change will have to merge first
14:27:47 <abhishekk> anything on hide old images?
14:27:57 <rosmaita> nope
14:28:12 <abhishekk> if anyone is not working then I might take that after next week
14:28:20 <rosmaita> no objection from me!
14:28:48 <abhishekk> ok
14:28:49 <rosmaita> jokke_ : here is a patch moving some implemented rocky specs to 'implemented': https://review.openstack.org/576996
14:29:37 <rosmaita> that will make it easier for moving more specs over the next few weeks
14:29:43 <rosmaita> :)
14:30:18 <jokke_> rosmaita: cheers ... will have a look. I was planning to do that at once when going through what renos we need, but that is gr8 start for it
14:30:35 <jokke_> nice to have the bits in place to do it
14:30:48 <rosmaita> yeah, both specs moved already have releasenotes
14:31:02 <jokke_> goodie
14:31:19 <jokke_> ok, anything else?
14:31:28 <abhishekk> nothing from me
14:31:55 <rosmaita> i have one more review, a spec-lite implementation for glance_store, if anyone wants to look: https://review.openstack.org/577011
14:32:58 <jokke_> rosmaita: yeah saw that
14:33:33 <jokke_> that should not interfere with either multi back-end nor multi-hash so I think that is fine
14:33:45 <rosmaita> i agree
14:35:22 <jokke_> I'd like to make really strong point that _if_ we are going to merge those, we need to prioritize them and apart from those 2 the top priority is to find a way we get rid of the /v1/ endpoint even if the underlying code cleanup gets done later
14:35:42 <jokke_> I don't want to find any new excuses from anyone why we should not get rid of v1
14:36:10 <smcginnis> ++
14:36:17 <abhishekk> sounds good
14:36:43 <jokke_> which reminds me, did you rosmaita get the grenade/tempest stuff sorted so that there is the option to disable the tests relying on that endpoint?
14:37:04 <jokke_> I remember you looking into it early at the cycle around PTG
14:37:35 <rosmaita> i think you are referring to the ability for glanceclient to test against both v1 and v2 even if v1 is removed from glance?
14:37:38 <rosmaita> that has merged
14:38:00 <rosmaita> the glanceclient v1 tests are currently being run against stable/queens glance
14:38:04 <jokke_> it was that one, yes I think that was the biggest blocker to get rid of those
14:38:37 <jokke_> gr8 ... I will have another look what breaks when removing the endpoint by end of this week
14:39:04 <jokke_> ok, I think that's all ... Thanks Everyone!
14:39:11 <abhishekk> thank you all, have a nice day ahead!!!
14:39:13 <jokke_> yell if something else
14:39:20 <jokke_> going 1st
14:39:22 <rosmaita> bye everyone!
14:39:34 <jokke_> going 2nd
14:39:37 <smcginnis> Thanks!
14:39:41 <jokke_> #endmeeting