14:01:43 <jokke_> #startmeeting glance
14:01:44 <openstack> Meeting started Thu Mar 28 14:01:43 2019 UTC and is due to finish in 60 minutes.  The chair is jokke_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:47 <openstack> The meeting name has been set to 'glance'
14:01:55 <jokke_> #topic roll-call
14:01:58 <jokke_> o/
14:02:09 <rosmaita> o/
14:02:26 <smcginnis> o/
14:02:41 <jokke_> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:02:45 <abhishekk> o/
14:03:01 <jokke_> cool we have everyone here
14:03:17 <jokke_> #topic updates
14:03:54 <jokke_> So looks like RC1 was success ... there's no critical bugs opened against it and it did not break the world \\o \o/ o// o/7
14:04:36 <smcginnis> Always nice when the world doesn't break. :)
14:04:48 <jokke_> yeah
14:05:02 <jokke_> also the osc goal discussion is still going https://review.openstack.org/#/c/639376/4/goals/train/osc.rst
14:05:43 <jokke_> Oh, and I fecked up ... totally missed the proposal window for forum sessions so we won't be having one
14:06:48 <jokke_> doing some finetuning on my mailing list filtering, hopefully will not miss such info in the future
14:07:07 <jokke_> on that note
14:07:13 <jokke_> #topic release updates
14:07:21 <jokke_> abhishekk: welcome back
14:07:27 <abhishekk> :D
14:07:40 <abhishekk> as you just said we have successful glance rc1 release
14:07:41 <rosmaita> yeah, the switch to openstack-discuss has been a PITA
14:07:49 <abhishekk> no bug reported yet
14:08:15 <jokke_> well there is a bug, but by quick glance it's brick not glance using the deprecated import
14:08:33 <abhishekk> regarding periodic job we are still hitting with py35 interpreter not found error
14:08:34 <jokke_> https://bugs.launchpad.net/glance/+bug/1821306
14:08:35 <openstack> Launchpad bug 1821306 in os-brick "Using or importing the ABCs from 'collections' is deprecated" [Undecided,New]
14:08:56 <smcginnis> Oh, I hadn't seen that one yet.
14:09:09 <jokke_> no actually we do it directly as well it seems
14:09:13 <smcginnis> Looks like it should be an easy fix in os-brick.
14:10:16 <jokke_> shouldn't be a big deal to fix and if that's the very only thing, I'm not sure fixing that warrants RC2 for us
14:10:36 <smcginnis> Good to get rid of deprecation warnings, but I wouldn't consider it a critical issue.
14:10:41 <jokke_> indeed
14:10:48 <abhishekk> I will try to contact infra team regarding the py35 interpreter error
14:11:20 <rosmaita> maybe we need to change those tests to use py36 ?
14:11:41 <abhishekk> might be
14:12:29 <smcginnis> Oh, could be now that legacy jobs were switched to run on bionic nodes.
14:12:40 <jokke_> So I thought there was some shifting around the py3 versions, not sure what we are actually supposed to be testing atm.
14:13:32 <rosmaita> py36 for stein
14:13:58 <rosmaita> gmann has had some patches up for the tempest and grenade stuff, i think
14:14:02 <jokke_> sounds kind of crazy that we're running tests on py 35, 36 and 37 but on the same time, the rate python is bringing backwards incompatibilities into 3.minor releases might be needed
14:14:07 <smcginnis> Yep, py36 is the default py3 for stein, py37 is good to test to make sure we are OK on the next bump.
14:14:47 <smcginnis> I believe in train we can make sure all the py35 stuff is gone. Only really needed for grenade upgrades if I understood right.
14:14:57 <jokke_> ok, lets swap the 35 tests to 36 and see if we get rid of those failures
14:15:52 <abhishekk> ack
14:17:42 <abhishekk> that's it from me
14:17:55 <abhishekk> (I thought, I got disconnected)
14:18:13 <jokke_> ok
14:18:15 <jokke_> moving on
14:18:34 <abhishekk> every thing on the agenda is rosmaita now :D
14:18:51 <rosmaita> :)
14:19:02 <jokke_> #topic queens backport
14:19:06 <rosmaita> acutally, it's me talking about abhishekk's stuff!
14:19:15 <smcginnis> :)
14:19:16 <jokke_> didn't copy the hash to the topic :D
14:19:30 <abhishekk> :d
14:19:46 <rosmaita> ok, i think someone hit the 'file' store missing bug yesterday in #openstack-glance
14:20:00 <rosmaita> #link http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-glance.2019-03-27.log.html#t2019-03-27T19:44:17
14:20:11 <abhishekk> Yes, I will backport it to queens (may be tomorrow)
14:20:13 <rosmaita> not sure exactly, but sounded liike it
14:20:27 <rosmaita> ok, i was just wondering if it will be a clean backport (i think so)
14:20:38 <rosmaita> ok, we can wait and see on that
14:21:07 <rosmaita> i think it would be worth doing new stable releases with that bugfix?
14:21:07 <smcginnis> Looks like it should be easy to backport. And good.
14:21:18 <rosmaita> ok, cool, that's really all i had on that
14:21:25 <jokke_> it should be as iirc it does not use the multi-store interface
14:21:31 <jokke_> kk
14:21:59 <jokke_> #topic inconsistencies in multistore API?
14:22:11 <rosmaita> ok, this may be controversial
14:22:22 <abhishekk> only case is that we didn't have tests in queens
14:22:35 <abhishekk> so we only need to backport the actual code
14:22:59 <rosmaita> i guess that's ok?
14:23:31 <abhishekk> I guess so
14:23:35 <jokke_> I would love to backport the tests as well, but if it's hell of a lot effort lets stick with the fix only
14:23:53 <jokke_> #undo
14:23:54 <openstack> Removing item from minutes: #topic inconsistencies in multistore API?
14:24:07 <jokke_> that all from it?
14:24:14 <abhishekk> yes
14:24:16 <jokke_> #topic inconsistencies in multistore API?
14:24:25 <rosmaita> i guess we can be confident that the rocky tests cover that part of queens?
14:24:27 <jokke_> lets try this again :D
14:24:32 <abhishekk> :D
14:24:33 <rosmaita> (sorry, my typing is slow)
14:24:56 <abhishekk> I am confident enough
14:25:19 <rosmaita> jokke_: ? smcginnis: ?
14:25:30 <rosmaita> i think i am ok with it
14:25:36 <jokke_> #undo
14:25:37 <openstack> Removing item from minutes: #topic inconsistencies in multistore API?
14:26:10 <smcginnis> Yeah, should be good. I like the idea of backporting the tests if it's not too much work.
14:26:30 <rosmaita> ok, we're not really in a rush on that
14:26:44 <rosmaita> we can let Abhishek do a backport and report back on the test situation
14:26:47 <abhishekk> I will try best to backport tests as well
14:26:50 <jokke_> well yeah ... it is deep stable ... like said in principle it would be great if we had the tests but if it's anyting else than finding the test patch and cherrypicking it in, lets forget it as we have already soon 2 stable branches in between
14:28:10 <abhishekk> ack
14:28:35 <jokke_> it's just matter of principle and having tests for bugfixes. but like said it's very unlikely we manage to backport something that breaks it over 2 stable branches without noticing (or that the same tests would catch there something they did not catch on previous merges/backports)
14:29:15 <jokke_> so definitely don't spend too much effort on the tests
14:29:19 <smcginnis> ++
14:29:23 <rosmaita> ++
14:29:48 <abhishekk> ok
14:30:11 <rosmaita> there is also the workaround of just having 'file' in the 'stores' config option
14:30:27 <rosmaita> am i right that as long as 'file' is in there, you don't hit the bug?
14:30:34 <abhishekk> yes
14:30:47 <rosmaita> ok, just wanted to verify
14:31:04 <jokke_> there is that but also the proper fix is well self contained so there is really no reason why we should not backport it
14:31:07 <rosmaita> i know i looked at it like a week ago, but it seems longer for some reason
14:31:26 <rosmaita> jokke_: i agree
14:31:27 <abhishekk> 2 weeks almost
14:32:01 <abhishekk> lets move ahead
14:32:13 <jokke_> rosmaita: anything else on this?
14:32:23 <rosmaita> not from me (for real this time)
14:32:31 <jokke_> #topic inconsistencies in multistore API?
14:32:45 <rosmaita> ok, the background is a spec abhishekk has for cinder
14:32:49 <rosmaita> #link https://review.openstack.org/#/c/641267/
14:33:03 <rosmaita> i was looking at our docs and api calls
14:33:14 <rosmaita> we use 'store' when we are talking to end users
14:33:32 <rosmaita> but we tend to use 'backend' also
14:33:50 <rosmaita> my question is whether we should be more consistent about this
14:33:58 <rosmaita> so that it's easier to configure, etc
14:34:06 <abhishekk> so you are suggesting to use store instead of backend?
14:34:11 <rosmaita> yes
14:34:21 <rosmaita> i think 'backend' shows up in the location metadata now?
14:34:24 <rosmaita> is that right?
14:34:36 <abhishekk> the reason I have choose backend is we already have default_store option
14:34:51 <abhishekk> for single store deployment
14:35:19 <rosmaita> yes, i kind of remember our discssion about this at the beginning of the cycle
14:35:27 <jokke_> yeah
14:35:42 <rosmaita> but i think we should use 'store' to the greatest extent possible
14:35:43 <abhishekk> and we can not use same option in case of multiple store deployment so I have renamed every option to backend i.e enabled_backends, default_backend etc
14:36:15 <rosmaita> ok, i think that is ok for operator only facing stuff
14:36:28 <rosmaita> but something a user might see should be a 'store', i think
14:36:32 <jokke_> it's one of these things where we can be user friendly by not accidentally breaking anything by overloading config options, etc. but then causing some confusion when we have "same" config options under multiple names for that
14:36:57 <abhishekk> yes
14:37:07 <rosmaita> i think the location metadata is the only place you'd see a 'backend' now as an end user?
14:37:16 <abhishekk> so we should rename --backend to --store?
14:37:20 <rosmaita> also in the glanceclient mabye? but we can fix that
14:37:26 <rosmaita> that is my thought
14:37:40 <rosmaita> since the api-ref is all talking about  stores
14:37:49 <jokke_> and probably call it --store-id
14:37:50 <rosmaita> and the http header is something-Store
14:38:06 <jokke_> just ot be super clear
14:38:15 <abhishekk> ok, I will identify al the cases including docs, input parameters etc and create one etherpad which will help us to identify the impact
14:38:21 <rosmaita> yes, since we use 'id' in the /info response, i agree that store-id is cool
14:38:47 <rosmaita> great, there is no rush on it, just before the API goes out of experimental
14:38:51 <rosmaita> we can assess at the ptg
14:38:59 <jokke_> IIRC the feature is experimental through all three repos so it should not be big deal to change
14:39:00 <abhishekk> cool
14:39:18 <rosmaita> i don't want to make a lot of extra work, but it will be good to be consistent as much as possible
14:39:18 <abhishekk> if it is simple change we can merge it before ptg as well
14:39:28 <rosmaita> abhishekk: ++
14:39:32 <jokke_> just lets add that to the list of multi-store stuff we need to address in PTG
14:39:42 <abhishekk> ack
14:39:44 <rosmaita> ok, cool
14:39:51 <rosmaita> that's all i have on this
14:40:20 <jokke_> I'd prefer not to act on the multistore stuff we consider changing before PTG so we have the whole picture how we are moving forward with that
14:40:36 <abhishekk> rosmaita, between, does cinder proposal looks good to you?
14:40:41 <abhishekk> jokke_, ack
14:41:13 <jokke_> If we have many things on our list I just schedule whole day for it
14:41:13 <rosmaita> abhishekk: i think so, i had some more comments, don't know if you saw them yet
14:41:26 <rosmaita> jokke_: ++ for multistore full day
14:41:34 <abhishekk> rosmaita, I have fixed them and uploaded new spec as well
14:41:43 <rosmaita> abhishekk: cool
14:41:58 <abhishekk> jokke_, ++
14:42:03 <rosmaita> i put your spec as a proposal for the cinder ptg sessions
14:42:21 <abhishekk> rosmaita, great
14:42:36 <rosmaita> would be good to discuss it quickly with the cinder team
14:43:00 <abhishekk> I am working on PoC for both proposed as well as alternative solution, once done I will share with you
14:43:11 <abhishekk> rosmaita, ++
14:43:16 <rosmaita> abhishekk: very nice
14:43:55 <rosmaita> jokke_: also the encryption key management thing, it's on both our and cinder's ptg etherpad
14:44:04 <jokke_> kk
14:44:50 <jokke_> anything else on this?
14:45:00 <rosmaita> not from me
14:45:32 <abhishekk> nope
14:45:34 <jokke_> #topic open discussion
14:45:48 <jokke_> rosmaita had something flagged here as well I think
14:46:05 <rosmaita> i just tossed some stuff on the etherpad in case we have time to sit down together and code at the PTG
14:46:16 <rosmaita> the first on is the config files
14:46:39 <rosmaita> we did a regen for abhishek's change to the cache management
14:46:56 <rosmaita> that config file is insane, it has all sorts of stuff that i don't think is needed
14:47:01 <rosmaita> but i am not 100% sure
14:47:19 <rosmaita> it would really help operators if we could sort those out a bit
14:47:26 <jokke_> I think it's pretty much the copy of -api.conf just different name for different config values if needed
14:47:35 <abhishekk> ++
14:47:35 <rosmaita> either that, or jsut have one super-duper config file and get rid of all these individual ones
14:47:46 <abhishekk> even same for scrubber.conf as well
14:47:54 <rosmaita> yes
14:48:25 <rosmaita> anyway, would be nice if we have time
14:48:28 <jokke_> I would really like to clean the config files up. For example remove all the redundant crap from the help texts to limit the size a bit ;)
14:48:49 <jokke_> I think -api.conf hit like 4 or 5k lines now
14:48:57 <rosmaita> well, there's some oslo.config stuff we're not taking advantage of
14:49:23 <rosmaita> like defining descriptions for individual enumeration items
14:49:38 <rosmaita> we did it by hand, but now there's some kind of oslo.config thing
14:49:42 <rosmaita> but the output includes both
14:49:50 <rosmaita> so you see our list of what the stuff means
14:50:03 <rosmaita> and then a list of each item with <no doc available>
14:50:27 <rosmaita> but, remember that that help text is really the configuration documentation
14:50:40 <rosmaita> so that's why it is verbose even though jokke_ doesn't like it
14:51:31 <jokke_> We have lots of verbosity there and then we have tons of redundant crap that is purely boilerplate overhead that provides no value
14:52:00 <jokke_> but increases the volume of those files by a lot
14:52:01 <rosmaita> i disagree about the no value ... the related items or no related items is pretty helpful
14:52:23 <rosmaita> yeah, well, an operator can run sed and strip out all the comments
14:52:52 <rosmaita> it's either that or maintain separate documentation for all of it
14:53:05 <rosmaita> and that gets out of date so fast it's not worth it
14:53:22 <rosmaita> anyway, we can discuss over beverages at the PTG
14:53:28 <jokke_> rosmaita: my point is not that the ones that has values should not be there, my point is that we have that crap there for every single option just to have it there even if it's just the key
14:54:17 <abhishekk> ++ for beverages
14:54:18 <rosmaita> jokke_: it's because if you let one option in with just a one-liner, everyone wants to do it!
14:54:24 <jokke_> it's like prepopulating all possible property keys to every imgage in glance just so that the user can see what would be possibly there ;)
14:54:58 <jokke_> rosmaita: and there is nothing wrong with that if the oneliner is explanary enough for the option documentation being clear
14:55:01 <rosmaita> i think i could use a beverage now
14:55:04 <jokke_> :D
14:55:12 <abhishekk> :D
14:55:28 <rosmaita> jokke_: everyone always thinks their oneliner is completely explanatory ... and they are pretty much never correct
14:56:21 <abhishekk> last 4 minutes
14:56:39 <jokke_> rosmaita: and that why we have something called code review to catch those. but "lets add 10 lines of boilerplating to every option because some of them might benefit the info being there" is giving us exactly what you wanted to clean up :D
14:56:48 <jokke_> fecking messy and insanely long config files
14:56:54 <rosmaita> anyway, if the config revamp is too controversial, my second suggestion is to actually remove some of the deprecated stuff
14:57:16 <abhishekk> agree to remove deprecated stuff
14:57:33 <rosmaita> we never get around to it, so it might be good to just sit down and do it all together
14:57:45 <abhishekk> +1
14:57:55 <jokke_> so we will be removing a lot in train taken that our deprecation of registry is finally up ... so we can clean all that out of there
14:57:59 <rosmaita> with beverages!
14:58:24 <jokke_> which will clean lots of the configs as well
14:58:26 <rosmaita> we could have a registry removal hackfest
14:58:40 <rosmaita> yeah, maybe let's do that first, and worry about configs later
14:58:42 <jokke_> including glance-registry.conf and glance-registry-paste.ini as whole
14:59:06 <jokke_> last minute, anything else?
14:59:21 <abhishekk> nothing from me
14:59:26 <rosmaita> we can have t-shirts "I removed the glance registry and all i got was this dumb T-shirt"
14:59:27 <abhishekk> thank you all
14:59:38 <abhishekk> +200
14:59:42 <smcginnis> Thanks!
14:59:49 <rosmaita> bye!
14:59:50 <smcginnis> rosmaita: ++ :)
14:59:51 <jokke_> rosmaita: *"registry/v1 api"
14:59:56 <jokke_> Thanks all!
15:00:10 <jokke_> #endmeeting