14:04:44 <rosmaita> #startmeeting glance
14:04:45 <openstack> Meeting started Thu Aug 30 14:04:44 2018 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:04:48 <openstack> The meeting name has been set to 'glance'
14:04:52 <abhishekk> o/
14:05:05 <rosmaita> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:05:51 <rosmaita> smcginnis may be occupied, coordinated release is happening as we speak
14:06:00 <abhishekk> yas
14:06:25 <rosmaita> so congratulations everyone for a successful rocky release!
14:06:37 <rosmaita> and, we already have a bug backport request on today's agenda!
14:06:43 <rosmaita> openstack does not stand still
14:07:03 <abhishekk> \o/ congrats
14:07:26 <rosmaita> ok, let's hold off on item 1 until jokke_ gets here
14:07:46 <rosmaita> #topic release update
14:07:59 <rosmaita> ok, rocky is now histoyr
14:08:03 <rosmaita> *history
14:08:15 <rosmaita> next milestone is Stein-1
14:08:20 <rosmaita> October 24
14:08:38 <rosmaita> what will go in there will be discussed at the ptg
14:08:49 <abhishekk> any update about your availability?
14:08:58 <rosmaita> will not be attending
14:09:00 <rosmaita> :(
14:09:09 <abhishekk> ohh :(
14:09:35 <rosmaita> do you have the link for the planning etherpad? the link on the agenda goes to an empty doc
14:09:48 <rosmaita> got it
14:09:58 <rosmaita> #link https://etherpad.openstack.org/p/stein-ptg-glance-planning
14:10:22 <abhishekk> https://etherpad.openstack.org/p/stein-ptg-glance-planning
14:10:31 <rosmaita> i think there is still time to get items on the agenda, so please check out the etherpad ^^
14:11:05 <rosmaita> ok, that's all the upcoming deadlines i am aware of
14:11:29 <rosmaita> the bug squad meeting scheduled for monday 3 Sept will not happen due to a holiday in the USA
14:11:43 <abhishekk> what about the backport, I guess sean as already voted +2?
14:11:50 <rosmaita> next bug squad meeting is Monday 17 Sept 10:00 UTC
14:12:06 <rosmaita> abhishekk you mean for the periodic tips job?
14:12:43 <abhishekk> rosmaita, sorry, I was talking about location update
14:12:53 <rosmaita> ah, ok, that's item 3
14:13:02 <rosmaita> i will hurry
14:13:34 <rosmaita> periodic tips jobs: looking good, one weirdness on glance functional py3 with glance_store, only failed once, i have not looked into it
14:14:11 <abhishekk> its wired exception, not able to reproduce that locally
14:14:20 <rosmaita> i hate it when that happens
14:14:40 <rosmaita> all right, that's all for release update
14:14:49 <abhishekk> so today I have setup new vm with py3, I will try again
14:14:58 <rosmaita> cool, ty
14:15:12 <rosmaita> #topic backport request to stable/rocky
14:15:26 <rosmaita> #link https://bugs.launchpad.net/glance/+bug/1750892
14:15:26 <openstack> Launchpad bug 1750892 in Glance rocky "Image remains in queued status after location set via PATCH" [Undecided,New] - Assigned to iain MacDonnell (imacdonn)
14:15:46 <rosmaita> this was fixed in master but after stable/rocky was cut
14:15:57 <rosmaita> probably around RC-2, so it didn't get into the release
14:16:08 <abhishekk> yeah
14:16:19 <rosmaita> i think it's worth backporting, it's a definite bug
14:16:28 <abhishekk> agree
14:16:39 <rosmaita> i have it tentatively assigned to rocky-bugfix-1
14:16:53 <rosmaita> but figure we should talk about it
14:17:12 <imacdonn> Ideally I'd like to backport it to Queens too ... it's a trivial fix, and the code around it doesn't appear to have changed
14:17:39 <abhishekk> sounds good
14:17:46 <rosmaita> i think that would be ok
14:17:59 <rosmaita> really need the PTL to decide this one, though
14:18:17 <abhishekk> may be sean or erno can vote on that
14:19:30 <rosmaita> i'll go ahead and add queens to the bug ... imacdonn go ahead and put up backports and we can discuss on the patches
14:20:00 <rosmaita> anything else about that issue?
14:20:07 <imacdonn> I was planning to cherry-pick to stable/rocky first, and it that's successful, repeat for stable/queens
14:20:37 <rosmaita> i think it would be ok to cp directly from master for both
14:20:42 <rosmaita> though i could be wrong about that
14:21:05 <rosmaita> i think rocky is very likely to be approved, queens is a bit more iffy
14:21:05 <imacdonn> yes, that's what I mean
14:21:47 <imacdonn> I can maintain internal patches if I must, but would be nice to not have to
14:21:58 <imacdonn> (internal to my employer org:)
14:22:12 <rosmaita> well, and other people may have the same issue, it's best to upstream if possible
14:22:18 <imacdonn> right
14:22:58 <rosmaita> you may want to mention in a comment on the backport to queens that you are actually encountering this issue in queens, it's not a speculative backport
14:23:37 <imacdonn> noted
14:23:46 <rosmaita> ok, cool
14:23:55 <rosmaita> #topic open discussion
14:24:14 <rosmaita> imacdonn you are the first item
14:24:28 * rosmaita has not read the spec lite yet
14:24:52 <rosmaita> btw, thanks for attending the meeting, i know it's very early for you
14:24:52 <abhishekk> even do I
14:25:25 <abhishekk> I think it's better to mention this spec in the ptg agenda?
14:26:06 <imacdonn> I'm not going to be at PTG (unless there's a way to remotely attend)
14:26:12 <rosmaita> yeah, but since neither imacdonn or rosmaita will be there, figured we could discuss now
14:26:19 <rosmaita> at least get some feedback
14:26:25 <abhishekk> sounds good
14:26:51 <rosmaita> imacdonn let me summarize and see if i have this right
14:27:01 <imacdonn> OK
14:28:24 <rosmaita> your proposal is that if an image is in queued status, and a user sets a location using PATCH (which is the only way to set the location), if the user includes 'checksum', 'os_hash_algo', 'os_hash_value' as location metadata, those values will NOT be kept in the location metadata but will be used to poupluate the "regular" image properties
14:29:13 <imacdonn> yes, and this is only allowed if the status is queued, and the items do not already have values (since there seem to be concerns about immutability)
14:29:46 <rosmaita> if the image is in "active" status, i guess a 400 response?
14:30:12 <imacdonn> I throw a HTTPConflict .. whatever that generates
14:30:30 <rosmaita> that's good , 409 i think
14:30:38 <abhishekk> I guess HTTPConflict sounds better
14:31:09 <rosmaita> imacdonn : can you add that to your spec?
14:31:19 <imacdonn> sure
14:32:11 <rosmaita> ok, my feedback right now is that there's nothing obviously bad about this proposal
14:32:15 <rosmaita> :)
14:32:57 <rosmaita> i think it's clear enough to use as a basis for discussion at the ptg
14:33:13 <rosmaita> abhishekk do you feel comfortable leading a session about it?
14:33:29 <abhishekk> rosmaita, yes
14:33:34 <rosmaita> great
14:33:51 <imacdonn> a little background ... we use the HTTP store extensively, and had been relying on the v1 API to register URLs on internal web servers by URL ... but since v1 is gone, I can't upgrade to Rocky ... so I need at least an agreed-on solution, which I'll backport to Rocky/Queens for internal use so I can proceed with the upgrade
14:33:51 <rosmaita> i was just thinking about the name clashes
14:34:03 <imacdonn> register images, rather
14:34:34 <rosmaita> we really don't want people putting checksums or multihash values in the location metadata, it should be on the image itself
14:34:44 <rosmaita> so i like the idea of rejecting those
14:34:45 <abhishekk> I will go through spec in detail and will get back to you guys if have any doubts
14:34:56 <rosmaita> ok, great
14:35:07 <rosmaita> imacdonn what was the other approach you had discussed with erno?
14:35:14 <rosmaita> something about a fake location or something?
14:35:53 <imacdonn> Yeah, his suggestion was to include an additional location with a fake URL like checksum://54fb6627dbaa37721048e4549db3224d
14:36:32 <rosmaita> i think i like using the metadata better, but that
14:36:36 <rosmaita> 's an alternatibve
14:36:48 <rosmaita> btw, i just noticed that glance channel is being logged again
14:36:56 <rosmaita> thanks to fungi for figuring it out
14:37:19 <rosmaita> ok, anything else about imacdonn
14:37:19 <imacdonn> The fake URL thing seems hacky, and maybe fragile
14:37:24 <rosmaita> 's proposal?
14:37:36 <rosmaita> imacdonn ++
14:37:44 <abhishekk> yeah its hacky
14:37:58 <rosmaita> even the metadata is a bit hacky, just not as icky
14:38:12 <imacdonn> just a side-note ... maybe you covered this already (I joined late)
14:38:41 <imacdonn> the specs repo needs updating to add the stein tree (and other thing, like closing out rocky specs) .... I guess that needs jokke_
14:39:04 <rosmaita> yeah, i saw brin gave him a shout-out in glance channel this morning
14:39:11 <rosmaita> now that it's being logged, he will see it
14:39:12 <abhishekk> yep
14:39:23 <rosmaita> only the PTL can merge into the specs repo
14:39:46 <rosmaita> the reason is that we want all the cores to sign off on each spec before it merges
14:39:48 <imacdonn> yeah ... seems that there maybe should be some way to delegate that if the PTL isn't going to be around .. but ok :)
14:40:11 <rosmaita> downside is a change like this that's purely structural has to wait, but that's the way it goes :(
14:40:47 <rosmaita> it's actually my fault, i forgot about waiting for everyone early in rocky and merged a spec that only had 2 +2s, not everyone's
14:41:18 <imacdonn> oops
14:42:07 <rosmaita> imacdonn you could rebase on brin's patch or maybe list it as a depends-on for your patch so that zuul will +1
14:42:43 <imacdonn> oh, I didn't know a depends-on would do that ... I'll try that when I add the HTTPConflict clarification
14:42:54 <rosmaita> i believe it will ... we can find out
14:43:27 <rosmaita> ok, anything else on locations checksum smuggling issue?
14:43:45 <imacdonn> I'm good .. thanks for the air-time!
14:44:16 <rosmaita> great, next topic is https://bugs.launchpad.net/glance/+bug/1779251
14:44:17 <openstack> Launchpad bug 1779251 in Glance "Unable to return list of all images (e.g. public + community) in a single request" [Undecided,New]
14:44:35 <andybotting> that's mine o/
14:44:41 <rosmaita> hi!
14:44:45 <andybotting> hi
14:44:47 <abhishekk> hi
14:44:57 <andybotting> thank for having me
14:45:01 <andybotting> thanks*
14:45:03 <rosmaita> i haven't had time to think about this yet
14:45:13 <andybotting> ok cool
14:45:24 <rosmaita> so the current situation is to see any community images, you need to add ?visibility=community
14:45:29 <rosmaita> even to see your own
14:45:30 <andybotting> we've basically worked around it in our cloud for now
14:45:37 <andybotting> yep
14:45:47 <andybotting> I have some background info here: http://lists.openstack.org/pipermail/openstack-dev/2018-August/133686.html
14:46:14 <andybotting> but we've moved all our public images to community in our cloud recently
14:46:26 <andybotting> and found a few little gotchas
14:46:30 <rosmaita> glad to see nectar is using this feature
14:46:41 <andybotting> it's perfect for us really
14:46:56 <andybotting> I was surprised that Horizon support was so minimal though
14:46:57 <rosmaita> ok, what happens if you use only owner=project_id as the filter?
14:47:15 <andybotting> that works fine
14:47:17 <rosmaita> horizon has had personnel issues (like us) recently
14:47:33 <rosmaita> andybotting so that includes all visibilities for the owner?
14:47:39 <andybotting> yes
14:47:49 <rosmaita> ok, just curious
14:48:21 <andybotting> so in the case of say, murano, it won't find community images that aren't owned by the project
14:48:28 <rosmaita> i see, so the issue is when i want to see what other peoples images are available to me
14:48:34 <andybotting> yeah
14:48:49 <andybotting> the biggest issue was with horizon's image launch wizard
14:49:07 <andybotting> it loads all images when the window opens, then does client side JS for filtering
14:49:20 <rosmaita> ok, it doesn't make multiple requests
14:49:22 <andybotting> it wouldn't work with community images at all
14:49:30 <rosmaita> we'
14:49:46 <andybotting> yeah, it should ideally do a new glance request when filtering
14:49:50 <rosmaita> d need it to make a public request, then a community request, and combine client side
14:50:05 <andybotting> yeah, i've done that in a patch i have
14:50:32 <andybotting> but my angular skills are non-existent
14:50:37 <rosmaita> ok, but you think it would be good for glance to do this as well
14:51:09 <andybotting> i think it would be useful to have an API request to get everything in one go
14:51:24 <andybotting> but I like that the default is to not show community images
14:51:33 <rosmaita> this is one of those cases where we say, use searchlight for sophisticated resource searching
14:51:46 <rosmaita> and searchlight is still a project in Stein!
14:51:51 <imacdonn> haven't thought this through, or studied it ... but it seems that if the default has always been to list all images that the project has access to (owned, or public), that should include community too
14:51:59 <imacdonn> on the API side, I mean
14:52:09 <rosmaita> well, we were worried about the spam potential
14:52:19 <rosmaita> decided to treat them separately
14:52:27 <rosmaita> so you only see them if you really want to
14:52:28 <andybotting> for us, we have like 12,000 images in total
14:52:31 <imacdonn> oh, because you can't make images public by default? (admin-only thing)
14:52:38 <rosmaita> imacdonn right
14:52:49 <imacdonn> yeah, ok, I guess I can see that
14:52:52 <andybotting> being able to push most of those to community which aren't shown by default makes glance much easier to deal with ;)
14:53:08 <rosmaita> andybotting are you aware of hidden images?
14:53:16 <rosmaita> new feature released today!
14:53:24 <andybotting> yeah!
14:53:28 <andybotting> looking forward to that
14:53:34 <rosmaita> so no horizon support yet either
14:53:47 <rosmaita> ok, so hidden would not work for what you want?
14:53:47 <andybotting> it'll be great for our image lifecycle
14:53:55 <andybotting> not in this case
14:53:59 <rosmaita> ok
14:54:05 <andybotting> it would be useful for our 'official' images
14:54:06 <rosmaita> andybotting will you be at the ptg?
14:54:21 <abhishekk> I guess again this needs to be discussed during ptg
14:54:22 <andybotting> but for those from our community, we still want them discoverable
14:54:33 <andybotting> my colleague will be
14:54:44 <rosmaita> yeah, i think this will benefit from in-person discussion
14:54:45 <andybotting> i'll be at the summit though
14:55:00 <rosmaita> andybotting can you propose this as a topic for the ptg?
14:55:09 <rosmaita> #link https://etherpad.openstack.org/p/stein-ptg-glance-planning
14:55:11 <andybotting> I'll add it to the etherpad
14:55:18 <abhishekk> Is it possible for him to drop by in one of the glance sessions?
14:55:34 <andybotting> yeah, I've spoken to him about it already
14:55:44 <abhishekk> great then
14:55:54 <rosmaita> that sounds good
14:56:00 <andybotting> great
14:56:03 <abhishekk> we have last 5 minutes left
14:56:11 <andybotting> thanks guys
14:56:18 <abhishekk> do we have meeting in next week?
14:56:28 <abhishekk> jokke_, will not be there,
14:56:33 <rosmaita> i think the plan was no meeting next week
14:56:37 <rosmaita> but i am not sure
14:56:53 <rosmaita> #action jokke_ send email to dev list about next few glance meetings
14:57:02 <abhishekk> Let's see if anything pops up on agenda then we can have it
14:57:16 <rosmaita> ok, watch the ML, i'm not sure if there will be a meeting or not
14:57:29 <rosmaita> i did mention no bug squad meeting on monday, though, i think?
14:57:49 <abhishekk> yes, you have mentioned that
14:58:01 <rosmaita> ok, that's all i have ... anyone else?
14:58:10 <abhishekk> nope
14:58:23 <rosmaita> ok, thanks imacdonn and andybotting for attending
14:58:32 <andybotting> thanks for having me
14:58:38 <abhishekk> thank you all
14:58:40 <imacdonn> We can chat about this in channel maybe, but I proposed this fix last night: https://review.openstack.org/#/c/597730/
14:59:18 <imacdonn> will be another backport thing, if we can agree on the fix
14:59:35 <rosmaita> yeah, that's one where we need an in-depth fix
15:00:01 <rosmaita> someone needs to read through the standards more carefully than i did
15:00:19 <abhishekk> time up
15:00:23 <imacdonn> Seems that headers are used much less extensively for the v2 API
15:00:32 <imacdonn> OK,see you in channel :)
15:00:32 <rosmaita> rfc's are mentioned in those comments if anyone has time to look
15:00:43 <rosmaita> ok, thanks everyone!
15:00:47 <rosmaita> #endmeeting