14:00:44 <abhishekk> #startmeeting glance
14:00:45 <openstack> Meeting started Thu Jan 16 14:00:44 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:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:48 <openstack> The meeting name has been set to 'glance'
14:00:54 <abhishekk> #topic roll call
14:01:02 <abhishekk> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:01:05 <abhishekk> o/
14:01:06 <rosmaita> o/
14:01:06 <jokke_> o/
14:02:00 <abhishekk> it's 3 musketeers
14:02:40 <rosmaita> :D
14:02:56 <jokke_> :)
14:03:02 <abhishekk> lets start
14:03:37 <abhishekk> #topic release/periodic jobs update
14:04:20 <abhishekk> We still have oslo job failure
14:04:46 <abhishekk> I have added workaround on the patch
14:05:16 <abhishekk> #link https://review.opendev.org/#/c/701580/
14:05:30 <jokke_> That' the one I think that we have patch up from Stephen as well
14:05:52 <jokke_> but the Stephen's patch were just removing registration of some options
14:06:03 <abhishekk> I am not able to find out root cause yet though, but added workaround and my understanding on the patch
14:06:17 <rosmaita> thanks for working on that
14:06:20 <abhishekk> jokke_, yes, I have added my suggestion there
14:06:31 <jokke_> yeah cool
14:07:03 <abhishekk> If we are good with that, then I can go ahead and update the patch with proper commit message
14:07:18 <jokke_> will need to look into it
14:07:43 <abhishekk> ack
14:08:01 <abhishekk> Ussuri milestone 2 - 5 weeks to go
14:08:02 <rosmaita> that really is weird, your guess does seem to make sense, though
14:08:23 <abhishekk> rosmaita, yes
14:08:57 <abhishekk> we need +2 from smcginnis on multiple import and copying specs to get those merged
14:09:19 <abhishekk> if he is around kindly ping him
14:09:41 <abhishekk> Need to release from stable train and stein branches
14:09:55 <abhishekk> I will propose release patches tomorrow my time
14:10:08 <jokke_> yeah, I think we should have everything merged in stable branches, right?
14:10:16 <abhishekk> jokke_, yes
14:10:41 <abhishekk> Only question I have here is do we need to propose separate release notes to stable branches?
14:10:50 <jokke_> abhishekk: I can do it today or we can push it to Monday, no Friday releases :P
14:11:20 <jokke_> abhishekk: I have done that in past if the patches has not contained renos
14:11:42 <abhishekk> jokke_, cool, if possible for you kindly propose the patches :D
14:12:17 <jokke_> kk
14:12:25 <abhishekk> thank you
14:12:31 <abhishekk> moving ahead
14:12:41 <abhishekk> #topic Multiple store import plugins
14:12:53 <abhishekk> multiple import specs
14:13:00 <abhishekk> #link https://review.opendev.org/669201
14:13:07 <abhishekk> Copying existing image specs
14:13:17 <abhishekk> #link https://review.opendev.org/#/c/694724/
14:13:31 <abhishekk> we need smcginnis to review and +2 these specs
14:13:59 <jokke_> ok
14:14:00 <abhishekk> Both are reviewed by other cores and have +2 from each of us
14:14:52 <abhishekk> yebinama is not around, but he has patch up which is working find
14:14:57 <abhishekk> s/find/sine
14:15:18 <rosmaita> that's good
14:15:20 <abhishekk> Only notification and documentation related changes are remaining now
14:15:42 <abhishekk> same thing for copying patch, only functional tests and documentation is remaining
14:15:55 <jokke_> yeah, I'll update my client patches once we have got the specs merged so we have tools to access these as well
14:16:03 <jokke_> and test them locally
14:16:11 <abhishekk> jokke_, great
14:17:04 <abhishekk> if you guys get some time, then kindly have a look at those patches and give your initial thoughts
14:17:11 <abhishekk> moving ahead
14:17:31 <abhishekk> #topic Delete image from single store
14:18:06 <jokke_> So we have some wording disagreements around comments, response messages and renos
14:18:15 <abhishekk> implementation,  https://review.opendev.org/698049
14:18:34 <rosmaita> i feel pretty strongly about not mentioning 'location' to end users
14:18:47 <rosmaita> we don't recommend that they be exposed
14:18:58 <rosmaita> so we should speak about 'image data' and 'store'
14:19:09 <abhishekk> ok, I didn't get enough time to have a look at the new patch
14:20:38 <abhishekk> I will go through it tomorrow my time
14:20:53 <rosmaita> we don't have naything else on the agenda ...
14:21:03 <abhishekk> rosmaita, no
14:21:07 <rosmaita> key thing woudl be to look at images.py
14:21:22 <rosmaita> would be good to get this out of the way now (though it is probably pretty late your time)
14:21:37 <abhishekk> Let me have a look
14:21:42 <jokke_> and I'm fine with that but I do feel quite strongly about consistency and specifically when we are responding of a same condition from multiple places. Thus like I already said, I'd rather keep the messages consistent and have discussion about what we return from our API to user as separate discussion outside of this review. That way we can update the responses where we need and be consistent
14:22:49 <rosmaita> ordinarily i would agree, but this is a new resource (/v2/stores) so we can treat it properly and then bring the rest into sync
14:23:53 <jokke_> Also we need to think how we communicate it so everyone understands what we are talking about. The "location" is very established term when we talk about images for long time already before multistore
14:24:15 <rosmaita> i disagree ... pretty much nobody understands locations
14:24:23 <rosmaita> and the default config doesn't expose them
14:24:34 <rosmaita> we're talking about end users here
14:25:12 <jokke_> default does not, I'd say around 68% (or what ever the ceph adoptation was on last survey) of deployments does
14:26:07 <rosmaita> doesn't matter, this is about stores
14:26:11 <jokke_> Like I said, I totally agree we should get away from it, but we need to do it consistently and not just somewhere and then forget everything else for few cycles
14:26:12 <rosmaita> so we should talk about stores
14:28:56 <abhishekk> I went through the comments
14:29:50 <rosmaita> you are going to have to put your foot down, because erno and i are not going to agree about this
14:30:02 <abhishekk> As we are talking about possibility of removing image from single store, it will be good to add messages which reflects the same
14:30:36 <abhishekk> this is my honest opinion
14:31:22 <rosmaita> what release are we going to make enabled_backends mandatory?
14:32:18 <abhishekk> rosmaita, it is not decided yet, but most probably from V release
14:32:31 <jokke_> I think original plan was this one, but I don't see it happening that fast
14:32:59 <jokke_> as I think we slipped already one cycle stabilizing it
14:33:07 <abhishekk> yes
14:33:24 <rosmaita> well, it does seem to be coming together nicely
14:35:13 <abhishekk> To make enabled_backends mandatory we need to make changes devstack as well :D
14:35:27 <rosmaita> that is always an adventure
14:35:41 <rosmaita> related to that, what's the status of making private visibility the default?
14:35:50 <jokke_> not gonna happen
14:35:55 <abhishekk> Nope, I have one patch up for the same which configures multiple file backends for us
14:36:12 <abhishekk> #link https://review.opendev.org/689104
14:36:58 <jokke_> rosmaita: effectively the QA stance is that we need to call it images api v3 to change any default values
14:37:12 <abhishekk> yes
14:38:12 <jokke_> rosmaita: the other option would be stop gating tempest :P
14:38:30 <abhishekk> lol
14:38:51 <rosmaita> bummer
14:40:16 <abhishekk> I will add my comments on the patch, but I think we should talk about the 'store' specifically instead of location
14:40:55 <abhishekk> jokke_, no offense :D
14:41:10 <jokke_> please, do then I have something to point out when people start nagging about inconsistencies saying "it wasn't me" and that's fine :P
14:41:13 <abhishekk> I have one item for Open Discussion, should we move ahead
14:42:01 <abhishekk> :D
14:42:19 <jokke_> so there is still the last sentence of the release note
14:43:11 <jokke_> should I just remove it as it seems like there is no agreement on that either
14:43:14 <jokke_> ?
14:44:12 <abhishekk> jokke_, looking
14:45:06 <abhishekk> I am fine with current wording here
14:46:01 <rosmaita> i just thought it a bit weird to be saying "hey, stuff might disappear, then you can use this new feature"
14:46:01 <abhishekk> will add my comment there as well
14:46:11 <rosmaita> doesn't seem like a good message
14:46:15 <rosmaita> but maybe i misread it
14:47:04 <jokke_> rosmaita: so let me explain my thinking on that.
14:47:16 <rosmaita> sure
14:48:36 <jokke_> Specially with the edge growing bigger and bigger with really small footprint sites. I'm expecting that lots of deployments won't have redundant storage across their sites. They count on edge site having failure, to rebuild that site clean
14:49:18 <jokke_> They will have like redundant central store and perhaps single glance node with file store at the edge
14:50:14 <jokke_> those edge sites will some point start failing and leaving data to the db which is just expected to be cleaned (and likely utilizing the async copy job) restored from central
14:51:25 <jokke_> I would never expect admin going willy nilly deleting data and not clening the mess behind them, but I would expect hw failures that might not have been backed up multiple times per day and restored to the pre failure state
14:52:23 <abhishekk> makes more sense
14:52:54 <rosmaita> ok, i understand.  it's just that "image data has for some reason disappeared from the store" seems a bit disconcerting
14:53:18 <jokke_> And I really don't want to throw our admins under the bus stating in the release notes that our expectation is, if you don't find your data in the store someone (admin) deleted it and forgot to tell you about it :)
14:53:52 <rosmaita> yeah, but we also don't want to give the impression that our software is so crappy that stuff can disappear from the store
14:53:56 <rosmaita> :)
14:54:04 <jokke_> no, but the hw is
14:54:13 <jokke_> and that just happens
14:54:13 <abhishekk> Last 6 minutes
14:54:29 <jokke_> ok, lets move on to abhishekk's open topic he had waiting
14:54:34 <rosmaita> sure
14:54:35 <abhishekk> I will add my topic to next weeks discussion
14:54:37 <jokke_> sorry for taking that long
14:54:53 <abhishekk> just to give idea
14:55:17 <abhishekk> we have a CLI tool for cleaning cache if it increases which is called glance-cache-pruner
14:55:40 <abhishekk> My opinion is unlike cache-prefetcher, we should run this also as a periodic job
14:56:08 <jokke_> you mean like prefetcher?
14:56:10 <abhishekk> I will write a lite spec for the same
14:56:47 <rosmaita> what's the advantage of cache pruning rather than just letting the ejection algorithm handle it?
14:56:50 <abhishekk> jokke_, now we have added prefetching as a periodic job
14:58:03 <abhishekk> rosmaita, I need to understand the existing tool, never used it
14:58:06 <jokke_> I think I have the same question as rosmaita
14:58:10 <rosmaita> iirc, our ejection algorithm was most-recently-used for a while, maybe that's why the tool was added
14:58:16 <rosmaita> yes, that's not a typo
14:58:24 <rosmaita> we were kicking out the newest image
14:58:42 <rosmaita> so you really did need to prune the cache to get anything to stick!
14:58:56 <abhishekk> but IMO instead of running it using cron job in deployments we should give this facilities to run as a periodic job
14:58:57 <rosmaita> i am pretty sure that actually happened
14:59:08 <jokke_> so in my understanding the cli tool was there for admin to make a call for what they want to throw out rather than letting the algo handle it
14:59:09 <abhishekk> last minute
14:59:22 <abhishekk> yes
14:59:28 <jokke_> Like I can't remember us running that in cron
14:59:37 <rosmaita> yeah, and a periodic job wouldn't know what to do in that case?
14:59:43 <jokke_> that's admin tool not periodic one iirc
14:59:44 <abhishekk> I am not sure there is any algo which is doing this
15:00:07 <abhishekk> OK, we can discuss this in next meeting
15:00:10 <abhishekk> thank you all
15:00:14 <jokke_> ok, we're out of time, I'll have a look into that as well
15:00:15 <rosmaita> sure, have a good evening
15:00:17 <jokke_> thanks all!
15:00:21 <abhishekk> #endmeeting