14:00:01 <jokke_> #startmeeting glance
14:00:02 <openstack> Meeting started Thu Jun 14 14:00:01 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:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:05 <openstack> The meeting name has been set to 'glance'
14:00:10 <jokke_> #topic roll-call
14:00:12 <jokke_> o/
14:01:03 <abhishekk> o/
14:01:37 <jokke_> lets give a minute or two to see if we get quorum
14:02:48 <abhishekk> ok
14:03:07 <smcginnis> o/
14:03:46 <jokke_> Hey Sean
14:03:55 <jokke_> ok, lets roll on
14:04:04 <jokke_> #topic updates
14:04:36 <jokke_> So couple of thing drawing attention
14:05:12 <jokke_> first the discussion for Stein Goals are ongoing atm. Keep your eye out for anything and everything and cheer in if you wish
14:05:38 <abhishekk> ok
14:05:39 <smcginnis> Input on goals is definitely appreciated.
14:06:21 <jokke_> the second one is https://review.openstack.org/#/c/570940/ which is interesting topic around our review principles
14:07:43 <jokke_> it looks like TC wants to push the responsibility of fixing commits to followups instead of asking the author fixing them
14:08:29 <jokke_> to be more "friendly"
14:09:55 <jokke_> third the Berlin summit presentation proposal window is now! So start drafting them talks
14:09:56 <smcginnis> Just for nits that don't really affect the fix.
14:11:30 <jokke_> We had milestone 2 last week
14:11:54 <jokke_> all 3 deliverables released
14:12:04 <jokke_> so we're well in that track
14:12:15 <jokke_> smcginnis: you have anything else from the release front?
14:12:39 <abhishekk> \o/
14:12:57 <smcginnis> Hmm, not that I can think of right now.
14:13:26 <jokke_> cool
14:13:40 <jokke_> #topic open discussion
14:14:09 <jokke_> So I wanted to quickly discuss about the multi back-end approach abhishekk is working on
14:14:24 <abhishekk> All patches related to multi-store are up
14:14:37 <jokke_> we had quick discussion at Tuesday around the the config approach
14:15:45 <jokke_> Honestly I did not have time yesterday to dig into it properly, but for you Sean TL;DR the approach Abhishek took was that the store parses the oslo config object for creating those store objects
14:16:50 <jokke_> and I was asking how difficult it would be to move that to glance side and have just api call for glance_store where the consumer of the lib could just pass the config details of the store and get the store object back
14:18:06 <abhishekk> https://review.openstack.org/#/q/status:open+topic:bp/multi-store
14:18:07 <jokke_> this would mean that a) the consumer would not be tied to oslo_config for their implementation and it would provide bit better isolation for stuff like our import staging and tasks work dirs
14:18:21 <jokke_> "and b) it would"
14:19:17 <abhishekk> IMO it will be much more difficult
14:19:20 <jokke_> but abhishekk's initial thought was that it might be quite a pain to implement so I just wanted to bring it up if that's something we should consider or are we fine having everything defined in the config object
14:20:43 <smcginnis> I do like the API discoverability. But it does sound like it would take quite a bit more work.
14:20:52 <jokke_> this was one of the points in the original store refactoring spec to make it more transportable and consumable and it would avoid us to do the nasty config overwrites internally
14:21:29 <jokke_> but I'm not sure if it's worth of the effort for this exact feature to land
14:21:31 <abhishekk> the main reason is even we have this in glance side then while staging call if we get the store object then we need to override the staging_uri value with filesystem_data_dir and then configure that store again otherwise those path will not be created and then again we need to restore original value and call configure method again
14:22:28 <abhishekk> I guess we should target refactoring of store differently (my honest opinion)
14:24:22 <jokke_> so one of the reasons for the multi-store expectations being so much work was that the refactor of the store api was taken as pre-requirement for this work being possible
14:26:12 <jokke_> now abhishekk has clearly proven it's possible without, my concern is does this make the refactor exponentially more difficult and unlikely to happen or do we still have hope to get decent api towards glance_store
14:27:56 <abhishekk> Another thing is we can have different glance_store api for staging (which will reduce the cost of building the store again)
14:28:02 <smcginnis> Not really sure, but seems like it's still a good thing to strive for. But good if it's not blocking current work.
14:28:15 <jokke_> also with the current approach we need to figure out how we flag the workdir for tasks and staging for import not being exposed as viable stores for images
14:29:02 <abhishekk> it's definitely not blocking the current work
14:31:48 <jokke_> Another thing we discussed around the multi-store was that i would like to have it as EXPERIMENTAL in Rocky, which would mean that if the new config options are not set, we would ignore the headers for target store istead of failing the call for wrong target. Flagging it EXPERIMENTAL would also mean that we would have opportunity to change things during Stain based on the feedback from the fiel
14:31:54 <jokke_> d before it's set to stone
14:32:23 <abhishekk> ++
14:32:24 <jokke_> also the discovery etc. would not work if not configured
14:32:34 <jokke_> similar way as the image import was in queens
14:32:39 <smcginnis> That sounds good to me. It would help if we can get something out and tested and see if there is anything we need to account for before it's set.
14:32:41 <jokke_> sorry, Pike
14:33:46 <jokke_> exactly, and knowing how much this feature has been requested for, I'd assume interested parties would use it and provide that feedback if something is horribly wrong about our initial approach
14:34:05 <abhishekk> agree with marking it as experimental thing
14:34:35 <smcginnis> The ability to get feedback from real users would be really good.
14:35:33 <jokke_> yeah ... which leads to the part I think I failed with image import ... we need to get strong word out to our user community to play around with it and provide that feedback
14:35:54 <abhishekk> these are some scenarios which I have documented for multi-store support https://etherpad.openstack.org/p/multi-store-scenarios
14:36:35 <abhishekk> I will also add nova and cinder related scenarios like boot instance, create snapshot, create backup, create volume, create volume-snapshot etc
14:36:42 <smcginnis> ++
14:37:00 <jokke_> we need to make it clear that it will be released stable in Stein and Stein cycle is the last chance to provide the feedback if something needs to change
14:37:03 <abhishekk> jokke_, ++
14:37:09 <smcginnis> A post to openstack-operators would be good to try to reach some of them.
14:37:40 <smcginnis> And I can try to retweet that to try to reach a few more.
14:37:49 <jokke_> ++
14:37:54 <abhishekk> ++
14:38:37 <jokke_> that's basically my thoughts/open questions around this. Just wanted to use this meeting time to get it out documented and your feel about it as well
14:38:51 <abhishekk> wondering, should I start working on writing unit tests for this?
14:38:52 <smcginnis> Think there would be enough to talk about with a Summit presentation on multi-store?
14:39:17 <jokke_> I think this is major thing enabling our users to do so much and we need to get it rightish
14:39:24 <smcginnis> ++
14:39:30 <smcginnis> abhishekk: I think so.
14:40:05 <abhishekk> ok, will start from next week and try to finish it in same week
14:40:41 <abhishekk> I will also prepare documentation and update api-ref (but need help on the grammar ;))
14:40:44 <jokke_> abhishekk: as you know I'm horrible in writing tests, but I'll try to spend more time on these changes and perhaps ping you with some test scenarios at least
14:40:50 <jokke_> if that helps
14:41:00 <abhishekk> jokke_, thank you
14:41:24 <abhishekk> I have some scenarios in mind, will create one etherpad for the same
14:41:26 <smcginnis> I can definitely help on any wording and documentation reviews.
14:41:37 <abhishekk> smcginnis, thanks
14:42:09 <jokke_> And Brian should be back next week so I'm sure he will give input to the doc wordings and reviews as well
14:42:20 <abhishekk> ++
14:42:41 <jokke_> lets keep the dock patches separate from the implementation, just for ease of review and going back and forth on them
14:43:01 <abhishekk> smcginnis, for start could you please look at the wording where I have added new config options in galnce and glance_store patches?
14:43:04 <abhishekk> jokke_, yes
14:43:57 <jokke_> we have 20min left. Anything you guys had on your minds for today?
14:44:06 <smcginnis> abhishekk: Will do!
14:44:13 <abhishekk> smcginnis, great
14:44:13 <smcginnis> Nothing from me really.
14:44:25 <abhishekk> jokke_, nothing from me as well
14:44:39 <abhishekk> jokke_, we should get update on multihash work
14:45:11 <jokke_> yeah I've been trying to chase Brian and Scott for that but they seem to be very busy on other things
14:45:18 <jokke_> will see how that folds
14:45:31 <abhishekk> ok, thank you for the update
14:45:59 <jokke_> actually!
14:46:52 <jokke_> Do we have something else we have totally neglected this cycle. I think the policy refactoring won't be happening at any level, the multihash is still on the air, anything else we're missing we agreed to do?
14:47:06 <abhishekk> hiding old images
14:47:36 <abhishekk> and removing migration scripts (which I will work after 2 weeks)
14:47:48 <jokke_> yes, at least that's been discussed and on the table all cycle unlike the 2
14:48:11 <abhishekk> https://etherpad.openstack.org/p/glance-rocky-priorities
14:48:27 <jokke_> ohh, that's something I have not kept track on, thanks for the reminder
14:49:06 <abhishekk> I am updating it time to time
14:49:58 <jokke_> yes, I've noticed "someone" updating the priorities pad, I meant the migration scripts I totally have "refused" in my mind
14:50:45 <abhishekk> we can revisit it in S
14:50:57 <jokke_> So the two things that are on my plate for R-3 and I might need some more help on these are how we kill the v1 API and getting the oslo.messaging rpc poc working
14:51:10 <abhishekk> That was again me from the mobile, while coming back to home ;)
14:51:56 <jokke_> so we have still a lot to do before wrapping this release together and not horribly much time
14:52:04 <abhishekk> I will try to sync on v1 removal after 10 days
14:52:22 <jokke_> lets take the last 8 min back and get to work :P
14:52:28 <abhishekk> :D
14:52:31 <jokke_> thanks all!
14:52:34 <abhishekk> thank you
14:52:57 <jokke_> #endmeeting