14:00:17 <jokke_> #startmeeting glance
14:00:18 <openstack> Meeting started Thu Jul 19 14:00:17 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:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:21 <openstack> The meeting name has been set to 'glance'
14:00:23 <jokke_> #topic roll call
14:00:25 <jokke_> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:00:28 <abhishekk> o/
14:00:28 <jokke_> o/
14:00:30 <smcginnis> o/
14:01:20 <rosmaita> o/
14:01:30 <jokke_> #topic updates
14:02:00 <jokke_> So it seems that the muti back-end did not break world. Well done abhishekk and the team!
14:02:12 <rosmaita> nice work, abhishekk
14:02:15 <abhishekk> :D, thank you all
14:02:26 <smcginnis> Woot! :)
14:02:54 <jokke_> so we're step closer to Rocky
14:03:42 <jokke_> which also means that if I saw correctly the Stain PTL election is starting very soon (I think I saw patch to add the election details to the page, but it has not been merged yet)
14:04:14 <smcginnis> Yeah, I think it's already next week. =:{
14:04:28 <rosmaita> wow, that's soon
14:04:42 <rosmaita> jokke_ you are doing a good job, care to continue?
14:04:45 <jokke_> obviously as usual gate is having tons of issues so what ever we need to get in needs tons of eyes
14:05:07 <jokke_> I'm gonna throw my name to the hat for second term
14:05:13 <smcginnis> Found the patch - PTL Nominations from 2018-07-24T23:45 to 2018-07-31T23:45
14:05:20 <abhishekk> great
14:05:27 <smcginnis> jokke_: Great!
14:05:43 <jokke_> that is not to discourage if anyone feels like taking over but I don't mind continuing
14:06:33 <abhishekk> I guess you should continue to take heat :P
14:06:38 <jokke_> but from that I pass over to rosmaita to get to business as I want to timebox sufficient discussion at the end for what we prioritize as we're running out of time
14:06:45 <jokke_> #topic release updates
14:06:46 <rosmaita> ok
14:06:54 <rosmaita> so periodic tips jobs are all green
14:07:08 <rosmaita> except one translate job that isn';t even ours, info on agenda
14:07:13 <rosmaita> i advise ignoring atm
14:07:27 <rosmaita> it's a glance_store trans job for stable/queens
14:07:41 <rosmaita> ok, glance_store rocky release must be today
14:07:52 <rosmaita> there are 3 patches to go in
14:08:04 <rosmaita> 2 are approved, just need to survive on zuul
14:08:16 <rosmaita> #link https://review.openstack.org/#/c/583942/
14:08:28 <rosmaita> needs reviews (has not passed first check yet)
14:08:42 * smcginnis queues it up
14:08:45 <rosmaita> i will update hash on release patch as soon as everything has merged
14:09:29 <rosmaita> smcginnis you will be around most of the day?
14:09:44 <jokke_> the whole set got bumped back to check queue
14:09:49 <jokke_> as in right now
14:10:04 <rosmaita> smcginnis and i can make sure 583942 gets in
14:10:10 <smcginnis> Yep, I should be here most of the day rosmaita
14:10:14 <rosmaita> cool
14:10:42 <rosmaita> if everyone agrees, smcginnis and i will carry over +2s and +As to the patches that had them before zuul went sideways
14:10:58 <abhishekk> no issues
14:11:01 <rosmaita> cool
14:11:30 <rosmaita> ok just a heads up that glanceclient final release is wednesday
14:11:42 <rosmaita> and RC-1 for glance is august 8
14:11:46 <rosmaita> that is all
14:12:14 <abhishekk> I have two patches for glanceclient, but I guess glance patches should get merged first right?
14:12:32 <jokke_> rosmaita: by the release schedule Thursday
14:12:48 <smcginnis> abhishekk: If you update them, might be good to put a Depends-on tag in there on the service side change.
14:12:55 <jokke_> there is no exception in the client release section from the standard Thu release day
14:13:11 <rosmaita> yeah but the code needs to be in on wed i think
14:13:14 <abhishekk> smcginnis, one patch already has depends on
14:13:19 <smcginnis> abhishekk: OK, great
14:13:24 <abhishekk> i need to check other patch
14:13:53 <smcginnis> rosmaita: It is Thursday by end of day, but shooting for Wednesday has always been my preference so there aren't any last minute scrambles and waiting on zuul queues.
14:14:09 <jokke_> smcginnis: ++
14:14:10 <rosmaita> which there will be!
14:14:18 <jokke_> indeed
14:14:18 <smcginnis> ALways ;)
14:14:50 <abhishekk> smcginnis, sorry both need to be add depends-on, I will do it later sometime
14:14:58 <jokke_> like we were so well in track with store, just to realize this morn that the 3 patches were missing which of one had not been even written yet ;)
14:15:30 <smcginnis> abhishekk: Only if you need to update. I just think it can help to make sure we don't land client support before the service support.
14:15:31 <rosmaita> luckily, none of those are serious changes
14:15:43 <abhishekk> smcginnis, ack
14:16:07 <jokke_> yeah the only one that is not really backportable is the cinder store one
14:16:56 <jokke_> ok, shall we move on?
14:17:09 <abhishekk> yes
14:17:09 <rosmaita> yep
14:17:24 <jokke_> #topic hidden images spec update
14:18:11 <abhishekk> rosmaita, thank you for your findings and review on spec
14:18:27 <rosmaita> np, i didn't get a chance to see your replies yet
14:18:47 <abhishekk> I was getting 409 error because I was trying to update image with --hidden with "true" and true
14:19:03 <abhishekk> pre-rocky glance ^^
14:19:12 <rosmaita> ok
14:19:44 <abhishekk> So rosmaita has one question, what about pre-rocky images which were having hidden as a custom property?
14:20:00 <rosmaita> i put up a paste with some info:
14:20:10 <rosmaita> #link http://paste.openstack.org/show/726229/
14:20:31 <rosmaita> i think anyone who has 'hidden' as custom metadata will just have it disappear
14:20:48 <rosmaita> don't think it's a big deal, tbh, but we should probably doc it in the release notes
14:20:53 <jokke_> I'll just jump in about the hidden. It's gonna be it's own column in the db and we have plan to use --hidden in client instead of the normal property mechanism which means that we just change is to os_hidden on api like we flag headers etc. as well. problem solved if someone has been using hidden already
14:20:53 <rosmaita> (which no one will read)
14:21:22 <jokke_> as indeed hidden is very easily overloaded
14:21:45 <rosmaita> that works
14:21:51 <abhishekk> so you mean to say new hidden column will be displayed on show as os_hidden?
14:21:55 <rosmaita> i think the multihash begin with os_
14:21:58 <jokke_> correct
14:22:00 <rosmaita> abhishekk yes
14:22:12 <abhishekk> ack, that will serve the purpose
14:22:21 <jokke_> it's not huge change and will solve the issue
14:22:36 <rosmaita> unless someone is using os_hidden as custom meta
14:22:41 <rosmaita> then same problem
14:22:45 <abhishekk> :P
14:23:02 <rosmaita> so i dont' know if it's worth worrying about
14:23:04 <jokke_> rosmaita: that's _their_ problem ... the os_ prefix has been clear purpos for years
14:23:14 <jokke_> purpose
14:23:25 <rosmaita> ok, makes a collision less likely, i agree
14:23:28 <abhishekk> so os_hidden is confirmed, I will mention this in spec as well
14:23:36 <rosmaita> but we will still need to mention disappearance in release notes
14:23:48 <rosmaita> abhishekk add that to spec update ^^
14:23:50 <abhishekk> will mention it in spec as well
14:23:54 <rosmaita> great
14:24:10 <rosmaita> ok, the other question was about when to allow hidden to be set on an image
14:24:37 <jokke_> #agreed rename hidden to os_hidden for avoiding collisions with possibly overloaded hidden property
14:25:10 <abhishekk> I guess it does not make sense to set hidden on image which is not active (my opinion though)
14:25:50 <rosmaita> well, if we allow it for image create, i think we need to allow for queued at least
14:26:02 <rosmaita> what problem do you anticipate?
14:26:09 <jokke_> if we are marketing it as lifecycle management I think it should be reserved images only. as it's more coming as "cleaning up the image list what the 3 previous visibility changes didn't do" feature I think we should not put artificial limits to it
14:26:37 <rosmaita> i agree with jokke_
14:26:49 <smcginnis> Makes sense.
14:26:53 <abhishekk> rosmaita, it can be a potential sec issue?
14:27:00 <jokke_> s/reserved images/reserved active images/
14:27:09 <jokke_> abhishekk: how so?
14:27:12 <rosmaita> abhishekk not sure .... what are you thinking?
14:27:15 <abhishekk> someone can create lots of queued image and hide it?
14:27:55 <rosmaita> well, once quotas are in, they will only affect themselves
14:28:05 <abhishekk> yeah
14:28:09 <jokke_> abhishekk: I really can't see attack vector there
14:28:19 <rosmaita> but people can do that now, create a lot of queued images that are not hidden
14:28:30 <rosmaita> good thing to think about, though
14:28:32 <abhishekk> I am interested to work on quota's
14:28:37 <abhishekk> jokke_, rosmaita agree
14:28:53 <jokke_> it makes it no less obvious if there is no rate limiting or any other ways to protect your cloud if those queued images are hidden or not
14:29:49 <abhishekk> In short, only active images should be allowed to hide, right?
14:29:50 <jokke_> One thing I was thinking of 'though ... do we remove the hidden flag when the image gets deleted?
14:30:08 <rosmaita> jokke_ why would that matter?
14:30:16 <abhishekk> jokke_, as of now no
14:30:23 <jokke_> abhishekk: no, I think as the feature really doesn't have lifecycle management focus, we should not limit it
14:30:41 <jokke_> rosmaita: does scrubber still see soft deleted images if they are hidden?
14:31:29 <abhishekk> jokke_, I guess yes, but will check and confirm
14:31:33 <rosmaita> we should check, but it goes directly to db to look for stuff
14:31:52 <jokke_> then it should not be affected
14:31:55 <rosmaita> i think it only looks at 'deleted' and 'deleted_at'
14:31:57 <rosmaita> right
14:32:07 <jokke_> as the db doesn't hide them, the api does
14:32:25 <abhishekk> it will not have impact
14:32:49 <rosmaita> cool
14:32:57 <abhishekk> so I will remove the restriction on hiding the image
14:33:03 <rosmaita> sounds good
14:33:22 <jokke_> ok, was that all for this?
14:33:31 <jokke_> do we know how to move forward?
14:33:32 <abhishekk> thank you, will update the specs and implementation accordingly
14:33:34 <abhishekk> yes
14:34:07 <rosmaita> thanks
14:34:08 <jokke_> #agreed "hiding" image should not have restrictions when it can be done during the image states.
14:34:35 <jokke_> ok moving on
14:34:45 <jokke_> #topic release priorities
14:35:24 <abhishekk> should we create another section here, https://etherpad.openstack.org/p/glance-rocky-priorities unless you have another etherpad
14:35:33 <jokke_> Now, we really have about a week to make the call what we are merging this cycle about these big features as they all part from v1 removal needs client components
14:36:24 <jokke_> And I would like to avoid backporting features to the client sencond release in a row if possible
14:36:35 <smcginnis> :)
14:36:37 <abhishekk> ++
14:36:49 <jokke_> thus we need to make priority list of what we commit to do over next 2 weeks
14:37:35 <jokke_> and I was willing to put the hidden images under axe before we got these questions solved few mins ago
14:37:51 <rosmaita> i think multihash is read-only, so should work in client when it gets updated schema
14:38:13 <jokke_> but my question really is, do we have enough time commitment to get multihash, multi back-end and the hidden images all merged to glance and client
14:38:16 <jokke_> ?
14:38:33 <abhishekk> multi-backend is almost ready
14:38:54 <smcginnis> Just looking where things stand today, I think multihash is the only major concern.
14:39:15 <abhishekk> hidden imgaes needs few touches which I will do by tomorrow EOD
14:39:19 <jokke_> so I'd say all of these are in good shape, the question really is do we as team have enough cycles in coming two weeks to ensure that we get the stuff merged?
14:40:09 <abhishekk> I think we should target backend and hidden images over next week and keep last week specifically for multi-hash?
14:40:36 <rosmaita> only problem is the experimental api
14:40:47 <jokke_> as I'm even willing to let the client stuff merge before the service patches merges if we commit to merge them and not to have last minute bikeshedding blowing the features out of the release
14:40:48 <smcginnis> I can't recall, is there a client side aspect of the multihash stuff?
14:41:05 <jokke_> rosmaita: there is that why I'm asking this
14:41:05 <abhishekk> We need API version patch
14:41:14 <rosmaita> i think it's just read only to display the value
14:41:40 <rosmaita> pretty sure v2 does not allow you to specify --checksum for image create?
14:41:48 <jokke_> it does not
14:41:50 <abhishekk> no
14:42:07 <rosmaita> ok, good, so no multihash either for symmetry
14:42:20 <jokke_> so only client side change we might need to do, is to ensure that multihash is displayed everywhere where the current hash is
14:42:38 <abhishekk> rosmaita, I can work on client patch for multi-hash
14:42:50 <rosmaita> abhishekk that would be cool
14:42:52 <jokke_> rosmaita: yeah, specially with the import and conversion stuff it's better not to allow it
14:42:59 <rosmaita> right
14:43:27 <abhishekk> ack
14:43:38 <rosmaita> abhishekk theoretically, shouldn't be too bad, should get constructed from the image json response like the rest of the image properties
14:43:52 <abhishekk> rosmaita, yes
14:44:04 <jokke_> so rc1 target is in 3 weeks
14:44:07 <rosmaita> but please feel free to do it!
14:44:20 <jokke_> R-3 is next week
14:44:37 <abhishekk> rosmaita, yep, will update you tomorrow this time around
14:45:39 <abhishekk> so after release of new glance_store my new glance unit and functional tests are passing for multi-backend
14:45:55 <jokke_> can we commit to have all these 4 things ready and reviewed in next two weeks if we leave room to FFE the multi back-end just for the purpose to make sure we get the API versioning right?
14:46:21 <smcginnis> Seems like that should be doable.
14:46:31 <abhishekk> yep
14:47:41 <rosmaita> i believe so
14:47:50 <jokke_> ok, then I'm gonna pull cheap one here. rosmaita the v1 removal passed tests, has 2x +2 and has not yet flagged for merge conflict. Could you please have a look over it this week?
14:48:05 <jokke_> that should be cheap one to get out of queue
14:48:10 <rosmaita> sure
14:48:27 <rosmaita> #action rosmaita review v1 removal patch
14:48:39 <rosmaita> (in a timely fashion)
14:49:17 <jokke_> then, get any client patches ready to go by monday preferably. abhishekk do not depend the multi back-end client patches to the API patches
14:49:40 <abhishekk> jokke_, that is ready then, just needs review
14:50:15 <jokke_> abhishekk: cool ... 'cause then we can merge the client patches in time for client release and commit having the API patches in last to get the versioning sorted
14:50:46 <abhishekk> jokke_, you need to approve v1 specs first before the patch merges
14:51:05 <jokke_> abhishekk: yeah that is pending smcginnis' ack
14:51:26 <jokke_> so smcginnis if you could check that spec amedment, would be great
14:51:37 <jokke_> there was some changes since your last +2 iirc
14:51:45 <abhishekk> https://review.openstack.org/#/c/580610/
14:51:48 <abhishekk> smcginnis, ^^^
14:51:52 <jokke_> or I might think some other spec
14:52:07 <smcginnis> Already in a tab, just need to get to it. But quick glance looks good.
14:52:32 <jokke_> smcginnis: yeah it's on my list so as soon as I see your +2 there I hit the +W
14:52:35 <jokke_> ;)
14:52:48 <smcginnis> jokke_: OK, I'll try to get to that quick.
14:52:50 <jokke_> take your time
14:54:35 <abhishekk> last 5 minutes
14:54:47 <jokke_> then I'd say don't hold your horses ... the multihash and hidden images changes should be driven in as they become ready. As long as they are API wise ok and functionally sound we can always tweak the minor details as bugfixes
14:55:04 <smcginnis> ++
14:55:09 <rosmaita> OK
14:55:27 <abhishekk> ok
14:55:53 <abhishekk> we need to documentation patches as well
14:55:55 <rosmaita> the glance_store check jobs are looking like another hour
14:56:09 <jokke_> #agreed we have commitment to merge v1 removal, multi back-end, multihash and hidden images to glance/python-glanceclient by the release deadlines
14:56:15 <jokke_> #topic open discussion
14:56:23 <jokke_> anything else for last minutes?
14:56:44 <abhishekk> nope
14:57:12 <jokke_> abhishekk: doc patches we can finalize by rc1 as long as the client renos are there
14:57:27 <abhishekk> sounds good
14:57:39 <jokke_> so lets focus on the functionality ... that's where we have the most of the panic
14:58:00 <jokke_> *have most*
14:58:48 <jokke_> ok, thanks all! Lets make this the greatest release ever ;P
14:58:50 <abhishekk> thank you all :D, have a good day ahead
14:58:53 <jokke_> #endmeeting