14:00:30 <rosmaita> #startmeeting glance
14:00:31 <openstack> Meeting started Thu Oct  5 14:00:30 2017 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:34 <openstack> The meeting name has been set to 'glance'
14:00:37 <gb21> hi
14:00:40 <rosmaita> hello everyone!
14:00:47 <McClymontS> Hey all
14:01:08 <croelandt> hey
14:01:17 <arcolife> \o
14:01:44 <abhishekk> o/
14:01:47 <rosmaita> arcolife sorry i didn't make it to the import testing meeting ... hope it was productive
14:02:14 <arcolife> rosmaita, no worries. abhishekk's UTC +5:30 fits well with our schedule :)
14:02:29 <rosmaita> i've got a hard stop at 14:45 today, so let's get started
14:02:33 <rosmaita> #topic updates
14:02:51 <rosmaita> spec freeze is tomorrow at 23:59
14:02:54 <rosmaita> that's all
14:02:57 <jokke_> o/
14:02:59 <rosmaita> #topic spec review
14:03:21 <rosmaita> i have an etherpad, let's go through the open specs real quickly to see what's up
14:03:34 <rosmaita> #link https://etherpad.openstack.org/p/glance-queens-spec-review
14:04:06 <rosmaita> ok, i am -2 on pending delete rollback proposal
14:04:13 <rosmaita> any contrary opinions?
14:04:47 <abhishekk> we can revisit it in next cycle
14:04:52 <rosmaita> good enough
14:05:10 <rosmaita> skip ossn-0075 for now
14:05:20 <rosmaita> hide old images from default image-list
14:05:52 <rosmaita> i don't see us having dev power ATM to do that, i think we should continue to refine it during the cycle and add to untargeted
14:05:53 <abhishekk> i like your idea of adding property instead of visibility
14:06:01 <rosmaita> abhishekk cool!
14:06:16 <jokke_> rosmaita: good on blocking those 2, I think the hiding as it is I'm leaned to -2 it and having it in the design of our lifecycle management planning rather than implement just that on it's own
14:06:25 <rosmaita> we may have some people joining us as the cycle develops
14:06:32 <McClymontS> I like the general idea
14:06:55 <rosmaita> ok, we'll not approve now, but agree to continue looking into this for R
14:07:02 <McClymontS> table it
14:07:04 <McClymontS> agreed there
14:07:34 <rosmaita> next up, multihash
14:08:34 <McClymontS> Believe the current spec is up to date on replies
14:08:35 <rosmaita> that looks pretty ready to go, if zuul will let it through
14:08:49 <McClymontS> Yeah looks like an issue with Zuul yesterday on a post failure
14:08:51 <rosmaita> i am +2 on that , and i think maybe jokke_ is too?
14:09:14 <jokke_> yeah, I  did not +2 it due to check failure
14:09:22 <McClymontS> will recheck today
14:09:28 <McClymontS> get it through the CI tests
14:09:37 <rosmaita> so the only revisions at this point would be if there's a syntax thing (doesn't look like that's the case though)
14:09:50 <jokke_> but the proposal as it is now looks fine. I'm not convinced we should have that update on download there, but that can be debated during the implementation
14:10:10 <rosmaita> i thought the update on download was removed?
14:10:13 <McClymontS> Got removed and became a discussion work item I believe
14:10:13 <rosmaita> scott?
14:10:14 <jokke_> McClymontS: oh hi there! Good to have you onboard
14:10:22 <rosmaita> cool
14:10:24 <McClymontS> Whats up, my pleasure to be here
14:10:29 <rosmaita> then that's all set
14:10:31 <McClymontS> I think its now a work item to merely discuss
14:10:55 <rosmaita> ok, inject metadata properties
14:10:57 <jokke_> rosmaita: so I just realized I have that daumn conversion spec to write
14:11:04 <jokke_> I totally forgot on the move hassle
14:11:08 <jokke_> will have that up tonight
14:11:17 <rosmaita> jokke_ i am thinking that is part of the IIR (more or less)
14:11:26 <McClymontS> jokke_ let me know when its up I'll try to review asap
14:11:48 <jokke_> rosmaita: if so, then I'm good with that ... can odcument it in a form of spec lite just to describe it
14:12:02 <rosmaita> jokke_ sounds good, let's do that
14:12:02 <jokke_> as the conversion is not part of the original spec discussion
14:12:38 <abhishekk> regarding inject metadata properties, I have uploaded the new specs just few hours before
14:13:05 <rosmaita> ok, i will read through after the meeting
14:13:15 <rosmaita> looks like erno is +2
14:13:24 <rosmaita> i don't anticipate any problems
14:13:30 <McClymontS> Nice
14:13:32 <abhishekk> thank you
14:13:48 <rosmaita> ok, add basic quotas
14:13:53 <rosmaita> i think we have to postpone that
14:14:07 <rosmaita> but we do need to do something in Rocky
14:14:19 <McClymontS> I will volunteer now to research that for R
14:14:26 <abhishekk> I will have a look on those as well
14:14:57 <rosmaita> ok, we should have a quotas meeting in a week or so to get scott up to speed on what the concerns are
14:15:12 <rosmaita> McClymontS you can be the quotas working group chair
14:15:14 <jokke_> sure
14:15:34 <McClymontS> Awesome let me know when it meets
14:15:45 <jokke_> I should be more or less on normal full blast next week ... Should get my internet finally sorted at Monday
14:15:46 <rosmaita> McClymontS will be up to you!
14:16:01 <McClymontS> Alright sounds good I will be sure to reach out
14:16:18 <rosmaita> McClymontS what i mean is that you can drive the effort to make sure we talk about quotas enough during queens so that we'll be ready to do something in R
14:16:32 <rosmaita> next up is language neutralization
14:16:57 <jokke_> McClymontS: I'm on GMT+1 due to dst still so please take that to account when scheduling and abhishekk is +5.5 ;)
14:17:17 <McClymontS> Sure thing all, I am in 7-5/530 EST most days so I can generally find time
14:17:21 <rosmaita> i think this is uncontroversial, let's get some +2s on it and move to untargeted
14:17:56 <rosmaita> queens community goal
14:18:21 <rosmaita> has one +2, i wrote it, so it's up to jokke_ ...
14:18:46 <rosmaita> it's kind of a drag, but i think we need to do it
14:19:00 <jokke_> do you have link for that? Can't seem to find it
14:19:11 <rosmaita> https://review.openstack.org/#/c/501869/
14:19:16 <rosmaita> sorry, being lazy
14:19:54 <rosmaita> finally, scrubber refactor
14:19:58 <rosmaita> https://review.openstack.org/#/c/507908/
14:20:16 <jokke_> that's the policy in goal, not the lang neuut
14:20:18 <rosmaita> we really need to do this one, and wxy has committed to working on it
14:20:28 <rosmaita> jokke_ sorry, didn't know which you wanted
14:20:43 <rosmaita> language neutralization: https://review.openstack.org/508566
14:20:54 <jokke_> thnx
14:22:14 <jokke_> ok that one ... weird it did not pop up on my spec search :(
14:22:38 <jokke_> so ... what config options we have there specifically that are affected?
14:22:47 <nikhil_k> ./
14:23:44 <rosmaita> jokke_ don't know off the top of my head
14:23:45 <jokke_> just wondering if it will make sense to wrap them instead of renaming them. What comes to the exceptions etc. I'm fully on board as we are pretty much wrapping them already in many places
14:24:09 <rosmaita> actually the exceptions look fine, as far as the class names go
14:24:14 <rosmaita> it's just the message text for exceptions
14:24:28 <jokke_> ok, so we can look into that during the work, I was just hoping we had list somewhere as the config options were specifically mentioned as I can't recall any
14:24:34 <rosmaita> i don't know about the config opts, can't remember off the top of my head
14:24:34 <McClymontS> To clarify thats a community goal too right?
14:24:43 <rosmaita> no, that's just for Glare
14:24:47 <jokke_> but there definitely is config options calling out "image"?
14:24:49 <McClymontS> oh okay my bdad
14:24:53 <McClymontS> oh okay my bad
14:25:01 <rosmaita> jokke_ i believe so, but don't remember
14:25:20 <rosmaita> that's going to go into untargeted anyway
14:25:28 <jokke_> ok, I'll check and give my review later today, NP
14:25:29 <rosmaita> let's ignore it for now
14:25:40 <rosmaita> i will research the config opt situation and put up a new patch
14:25:58 <rosmaita> key thing is to get the scrubber approved
14:27:09 <rosmaita> ok, now the elephant in the room, the ossn-0075 spec
14:27:25 <jokke_> I keep eye on it an once we get zuul result for it will cast my +2
14:27:29 <rosmaita> https://review.openstack.org/#/c/468179/
14:27:35 <jokke_> scrubber ^^ that is
14:27:45 <rosmaita> yeah, i figured :)
14:28:17 <rosmaita> ok, so the ossn-0075 fix
14:28:46 <rosmaita> proposal is to restrict it by policy, default no one can do it (where "it" is specify an image uuid on image-create)
14:29:04 <jokke_> and my -2 stands on that approach
14:29:18 <rosmaita> ok, i can respect that
14:29:29 <rosmaita> but i think we should do it anyway
14:29:31 <rosmaita> operators are on board
14:29:35 <rosmaita> api-wg is on board
14:29:45 <jokke_> there is so far nothing that has came up why we should do that instead of the less intrusive ways to track and sort the issue
14:29:51 <rosmaita> and i do not want to implement any code that requires an unbounded size DB table
14:29:58 <rosmaita> jokke_ ^^
14:30:04 <McClymontS> agreed on the DB point
14:31:20 <rosmaita> there is even operator support for not allowing the functionality at all
14:31:35 <rosmaita> i think the policy is a good compromise
14:31:51 <rosmaita> but i don't want to mess around with a complicated fix for a low-usage feature
14:32:05 <jokke_> rosmaita: I think it's quite biased to go that far based on one operator review
14:32:12 <McClymontS> tough to find a middle ground on this imo
14:32:27 <rosmaita> jokke_ point taken, but it's all the data we have
14:32:41 <rosmaita> the most alarming thing is 1/2 the respondants were not aware of OSSN-0075
14:32:45 <rosmaita> but that is a different issue
14:33:20 <rosmaita> i think that we have the ability in queens to search for image by sha512
14:33:28 <jokke_> rosmaita: I'd bet 100% of those were not aware of the db-purge with never had need to use it
14:34:09 <rosmaita> my feeling is if you are running a small cloud, do what you want (and you can by policy)
14:34:21 <rosmaita> if you are running a large cloud, you do not want to allow this
14:34:39 <jokke_> rosmaita: we have ability to search images with all kind of parameters, but there is 1 of them you can pass to nova and happens to be unique
14:35:07 <rosmaita> yes, but you can get it by querying glance first
14:35:30 <rosmaita> look if people really want to enable this, the policy allows that
14:35:36 <rosmaita> but we do not recommend it
14:35:56 <jokke_> rosmaita: I'd say policy restricting this (as using policies for about anything else as well) is one of those things that just throws all the interoperability discussion out of the window
14:36:19 <rosmaita> well, i completely disagree for this case
14:36:23 <rosmaita> as i wrote on the spec
14:36:35 <rosmaita> you have to be open to the possibility that the uuid is in use
14:37:01 <rosmaita> and in that case, you either have a plan B or no plan
14:37:12 <rosmaita> so same situation with the policy configuration
14:37:36 <jokke_> true, at which point you can always retry, it does not mean that every single uuid is in use like the policy makes it look like
14:38:20 <rosmaita> yes, but like i said, if you're use case is to give your image in region A the same UUID as in region B, and it fails, you are NOT going to try again anyway
14:38:45 <rosmaita> i really don't see this as a big interoperability issue
14:39:20 <rosmaita> and i don't want to fix a security problem with an implementation that allows a linear DOS attack
14:39:48 <rosmaita> the spec was metioned on the operators' list twice
14:39:54 <jokke_> rosmaita: well between regions/clouds you would. Like your own example where you have the external (Jenkins or what ever job) creating the images, you can allways retry with new uuid before uploading any of them ... uuid collisions are extremely rare after all
14:39:57 <rosmaita> once when it was introduced, and then last week
14:40:22 <rosmaita> jokke_ look, if you are doing all that with jenkins, you can be creative and work something out
14:40:52 <rosmaita> key think is the ossn was issued in sept 2016
14:40:59 <rosmaita> we need to do something
14:42:06 <jokke_> so I assume we won't get an agreement over next 15min so let's continue this offline and move on for now
14:42:32 <McClymontS> Agreed, I am pretty split as well.. although I don't have as much background I will try to get up to speed to help out
14:42:36 <rosmaita> ok, that's all then ... i just realized that i never heard from interop people about this
14:42:42 <rosmaita> i will ping them again
14:42:53 <rosmaita> let's agree to continue discussion and give this a spec freeze exception
14:43:03 <jokke_> ++
14:43:03 <rosmaita> it needs to be fixed in queens, no question about that
14:43:10 <McClymontS> Awesome, we can circle back over the next day to discuss
14:43:15 <McClymontS> or even next week
14:43:44 <rosmaita> #topic Glance Bug for Oslo.policy authorization request
14:43:54 <rosmaita> #link https://bugs.launchpad.net/glance/+bug/1720354
14:43:55 <openstack> Launchpad bug 1720354 in Glance "Glance doesn't send correctly authorization request to Oslo policy" [Undecided,New]
14:44:11 <rosmaita> i have not had time to look at this, but someone was going to lead discussion?
14:44:34 <jokke_> this is interesting one, I tried to read it through few times. Anyone able to explain to me in simple English what's actually broken?
14:44:46 <asteroide_> Hello, my collegue ans fill this bug
14:45:25 <asteroide_> in fact we develop a new solution for authorization in Openstack
14:45:41 <asteroide_> and we found this
14:46:17 <asteroide_> when we need to authorize a particular action you send though oslo_policy some information
14:46:36 <asteroide_> for example "openstack create image ..."
14:47:09 <asteroide_> this action is sent to oslo_policy and then to our framework the the http_check in oslo_policy
14:47:29 <croelandt> Has this ever worked?
14:47:37 <abhishekk> I was not aware that we can define something like '"add_image": "http://moon:8081/authz/wrapper"' in policy
14:47:52 <asteroide_> with the basic check (ie policy.json) it works
14:47:54 <croelandt> If you look at my comments on this bug, you can see why I'm wondering that :)
14:48:11 <jokke_> asteroide_: so you're pointing the policy engine to external uri and you control that external uri via some inhouse code and that doesn't work?
14:48:25 <asteroide_> yes
14:49:04 <asteroide_> there is an error in oslo_policy due to the content of the information given by glance
14:49:32 <asteroide_> oslo_policy cannot deep copying the value
14:49:50 <croelandt> + cant call keys(), + cannot use jsonutils.dump() on it
14:53:01 <jokke_> asteroide_: so I just had a quick glance through our policy documentation and I don't see any reference us allowing URIs as our policy rules. And this is the first use case I've heard for such
14:53:15 <jokke_> I did not know that oslo.policy even supports such
14:53:29 <rosmaita> me neither
14:53:33 <asteroide_> it works for nova and keystone
14:53:36 <abhishekk> me too
14:53:56 <asteroide_> We already had discussion with the oslo team
14:53:59 <jokke_> so I'd be inclined to state this is not a bug
14:54:08 <rosmaita> sounds like a feature enhancement?
14:54:11 <abhishekk> so we need to adopt that support?
14:54:22 <jokke_> that's my feeling as well
14:54:23 <rosmaita> asteroide_ we need some clarity around exactly what the problem is
14:54:39 <rosmaita> if we are breaking oslo, then it's a bug
14:54:53 <rosmaita> but if we are not supporting something exceeding oslo.policy, then it is not a bug
14:55:25 <rosmaita> and if oslo.policy is evolving to support something new, then it's somewhere in between
14:55:54 <rosmaita> guess it would be a spec lite, assuming the oslo.policy change does not break backward compat
14:56:07 <McClymontS> need more on this one
14:56:13 <rosmaita> asteroide_ do you understand our questions?
14:56:18 <abhishekk> I will have a look around nova and glance implementation
14:56:20 <rosmaita> let's discuss this again next week
14:56:31 <asteroide_> rosmaita:  yes
14:56:33 <McClymontS> Awesome sounds good to me
14:56:34 <rosmaita> sorry that the spec discussion took so long
14:56:47 <rosmaita> ok, asteroide_ i will put it first on agenda for next week
14:56:52 <asteroide_> ok
14:56:57 <rosmaita> #topic general discussion
14:57:10 <rosmaita> i'm going to have to run in a minute
14:57:20 <rosmaita> but anyone have a general comment or concern?
14:57:20 <McClymontS> Same here, will recheck multihash today
14:57:51 <jokke_> Just, I'd like to get common understanding about our spec freeze
14:57:53 <abhishekk> if time permits please have a look on https://review.openstack.org/#/c/433934 during this week
14:58:43 <abhishekk> thank you all
14:58:46 <jokke_> as there has been plenty of zuul issues lately, do we agree that the ones we discussed today and are comfy to implement during this cycle will be ok going in past the freeze _if_ the delay is due to gating issues?
14:59:19 <rosmaita> yes, agreed
14:59:24 <McClymontS> definitely agreed
14:59:28 <jokke_> as in let's not get stuck in technicalities :)
14:59:35 <abhishekk> agreed
14:59:47 <rosmaita> ok, thanks everyone!
14:59:53 <jokke_> cool ... I keep an eye on stuff and rather recheck than block anything that seems to be delayed
14:59:53 <rosmaita> #endmeeting