14:00:08 <nikhil> #startmeeting glance
14:00:09 <openstack> Meeting started Thu Jun 23 14:00:08 2016 UTC and is due to finish in 60 minutes.  The chair is nikhil. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:13 <openstack> The meeting name has been set to 'glance'
14:00:15 <nikhil> #topic agenda
14:00:20 <nikhil> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:00:49 <mfedosin> o/
14:00:57 <sigmavirus24> o/
14:00:58 <tsymanczyk> \o
14:01:13 <rosmaita> o/
14:01:23 <abhishek> o/
14:01:24 <nikhil> let's get started
14:01:33 <bunting> o/
14:01:35 <nikhil> #topic Updates
14:01:39 <vkmc> o/
14:01:41 <nikhil> #info Glare updates
14:01:46 <nikhil> mfedosin: ^
14:01:58 <dshakhray> o/
14:02:20 <mfedosin> hey :) pls, review the spec!
14:02:45 <mfedosin> #link https://review.openstack.org/#/c/283136/
14:03:02 <mfedosin> jokke_ added good comments
14:03:08 <kairat> o/
14:03:22 <mfedosin> I almost agree with him
14:03:43 <mfedosin> about the code - code is on review as well
14:04:17 <mfedosin> #link https://review.openstack.org/#/c/330459/3
14:04:30 <mfedosin> it's the top commit
14:04:46 <mfedosin> now I'm working on sqlalchemy db api for glare v1
14:05:13 <mfedosin> kairat added microversions support and did a small refactoring of our engine
14:05:43 <mfedosin> dshakhray is implementing json schema generation
14:06:53 <mfedosin> btw Darja defended her degree work today!
14:07:02 <rosmaita> go Darja!
14:07:09 <tsymanczyk> woo!
14:07:16 <mfedosin> and got excellent mark
14:07:36 <jokke_> :)
14:08:01 <mfedosin> The work was about the distinction layer in Glance
14:08:05 <mfedosin> #link https://review.openstack.org/#/c/331000/
14:08:13 <mfedosin> so, congratulations
14:08:24 <nikhil> congrats!
14:08:27 <mfedosin> sorry for offtop :)
14:08:41 <sigmavirus24> Would give dshakhray a round of applause but IRC isn't conducive to that
14:08:43 <mfedosin> so, we're waiting for reviews from community
14:08:52 <vkmc> \o/
14:09:28 <nikhil> o/\
14:10:01 <nikhil> should we move on to next?
14:10:27 <mfedosin> I think yes
14:10:30 <nikhil> #info Nova v1, v2 ( mfedosin )
14:10:34 <mfedosin> nothing
14:10:54 <kairat> can we remove this item?
14:11:13 <nikhil> do we know if Nova is happy with v2 testing?
14:11:13 <mfedosin> yes
14:11:29 <mfedosin> I know, we found a small issue there
14:11:34 <mfedosin> but it was fixed
14:11:50 <nikhil> kairat: I think we can bring this up once in a few weeks but not needed for all meetings anymore.
14:11:52 <mfedosin> nova could create kernel_id as empty string
14:12:07 <mfedosin> but v2 schema rejects it
14:12:17 <kairat> nikhil, agree
14:12:20 <mfedosin> so now we convert '' to None
14:12:30 <mfedosin> but I want to add another item here
14:12:59 <mfedosin> as you may know Murano, Horizon and Heat haven't supported v2 yet
14:13:15 <rosmaita> :(
14:13:23 <mfedosin> I work with all these team to help them adopt v2 in Newton
14:13:37 <mfedosin> so I may tell you about the progress
14:14:08 <nikhil> good idea
14:14:18 <nikhil> I've added it for next meeting.
14:14:27 <mfedosin> in short everyone wants copy-from
14:15:04 <mfedosin> Horizon team started to implement their own copy-from
14:15:15 <mfedosin> the same story for Murano
14:15:47 <mfedosin> if you give me 30 seconds I'll find this code for Horizon
14:16:08 <nikhil> while I empathize those teams calling it copy-from, it's not technically copy-from as far as glance is considered because that sort of implementation doesn't support the use cases of copy-from, particularly of large clouds.
14:17:39 <nikhil> should we move on for now?
14:17:49 <mfedosin> unfortunately I couldn't find this commit
14:17:57 <mfedosin> but I will next week
14:18:03 <nikhil> ok, thanks.
14:18:05 <mfedosin> okay, move on
14:18:35 <nikhil> #info Nikhil is travelling/limited online next week. rosmaita has graciously accepted to conduct the next thur's weekly meeting.
14:18:50 * rosmaita blushes
14:19:14 <nikhil> #topic better policy control on default policies and security issues (rosmaita , bunting )
14:19:36 <nikhil> #link https://review.openstack.org/#/c/309346/
14:19:49 <nikhil> #link https://review.openstack.org/#/c/330443/
14:20:04 <rosmaita> the basic problem is that bunting proposed adding some policies so that someone other than the glance admin ...
14:20:10 <rosmaita> a security team, say ...
14:20:17 <rosmaita> could download a deactivated image
14:20:21 <rosmaita> but the problem is
14:20:37 <rosmaita> if we add the policy download_deactivated_image
14:20:50 <rosmaita> the old policy files have default:"" in them
14:21:06 <rosmaita> so, unless the operator knows to specifically override the new policy
14:21:12 <rosmaita> everyone can do it
14:21:20 <rosmaita> which of course is bad
14:21:25 <bunting> This was on the mailing lint as well: http://lists.openstack.org/pipermail/openstack-operators/2016-June/010791.html
14:21:33 <bunting> Removing the need for a default role
14:21:54 <rosmaita> so we are wondering what's the best way to change this
14:22:17 <rosmaita> also, should the default role be "!" or "admin" or something
14:22:25 <rosmaita> because "" seems way too permissive
14:22:55 <jokke_> rosmaita: I don't see that in our current policy.json
14:23:31 <rosmaita> hmmm ... would've sworn it was in there
14:23:44 <jokke_> oh it's coming via "default": ""
14:23:50 <rosmaita> right
14:24:05 <tsymanczyk> fwiw the first thing i did when rewriting the keystone policy (locally) was default:"!"
14:24:15 <rosmaita> yes, so any policies not specifically mentioned in the file will do whatever default says
14:24:19 <nikhil> rosmaita: default just for deactivated images or every change like this?
14:24:29 <jokke_> so personally I think we need to overwrite that default on the rules we expect to defaulting to admin in the code and document that well
14:24:51 <rosmaita> tsymanczyk: ++ jokke_: ++
14:24:59 <rosmaita> my worry is how about upgrades?
14:25:18 <rosmaita> an old policy file based on our default will have default:"" in it
14:25:35 <rosmaita> is a strongly-worded release note sufficient?
14:25:36 <jokke_> rosmaita: that's why I'm saying in code, not in the example json
14:25:49 <bunting> What I think is that we go with !, and then move to using the new way of doing things in that mailing list reply
14:26:07 <bunting> Which is "It works by having every rule that a project
14:26:08 <bunting> uses register a default policy for that rule"
14:26:12 <jokke_> if we go with default "!" that blows all our tempest tests
14:26:48 <rosmaita> jokke_: good point
14:27:15 <nikhil> yes, default rule for all policy changes is breaking change
14:27:18 <sigmavirus24> (which probably also breaks defcore)
14:27:26 <jokke_> sigmavirus24: absolutely
14:27:28 <rosmaita> arrrgh
14:27:30 <hemanthm> jokke_: if we override the default in code, is that going to create confusion? (maybe it doesn't matter in the upgrade case here)
14:27:34 <nikhil> if we want to scrutinize changes, we can introduce a stringent role
14:27:44 <hemanthm> because it's sorta implicit
14:27:45 <rosmaita> hemanthm: ++
14:28:01 <jokke_> hemanthm: absolutely is, that's why we need to document it well and think really really carefully where it's appropriate
14:28:05 <sigmavirus24> rosmaita: I'm wondering if operators really never update their policy.json
14:28:27 <nikhil> I don't quite get what overriding means here. we may make the policy control redundant?
14:28:48 <jokke_> but if we want to move some of our hardcoded admin actions to policy, that's the _only_ way to go without exposing during upgrades
14:29:12 <rosmaita> nikhil: i think the idea (for Ocata) is that we have a hardcoded per-policy default that can be overridden
14:29:16 <jokke_> and/or breaking everybody in the action
14:29:22 <rosmaita> by the operator setting a specific policy
14:29:37 <bunting> rosmaita: ++
14:29:39 <rosmaita> but since the default is per-policy, we don;'t have to have the same default for all actions
14:29:51 <nikhil> I like that
14:30:31 <nikhil> it fits with the reasoning of obscuring secuirty issues with feature-wise policy support
14:30:59 <rosmaita> ok, so for now, what do we do? i guess leave default:"" for tempest?
14:31:06 <rosmaita> and strongly worded release note?
14:31:21 <nikhil> rosmaita: my question only was if we were going to override in source code or some way in the policy file?
14:31:56 <hemanthm> rosmaita: +1
14:32:01 <bunting> Why don't we move it upto admin at least?
14:32:07 <jokke_> nikhil: so problem with doing that in the policy file is that that demands ops catching that in upgrade and remember to upgrade their policy files
14:32:12 <rosmaita> nikhil: haven't thought this through, but i think we would eliminate "default" as a thing in the policy file
14:32:30 <rosmaita> instead, there would be a hard-coded default (in code, but also documented)
14:32:40 <nikhil> my opinion is that, this is a operator issue for which a hack is not worth
14:32:46 <rosmaita> and if the policy is mentioned in policy.json, we go with that instead
14:33:14 <nikhil> hmm, a good point worth discussion
14:33:18 <nikhil> worth a lite-spec I'd say
14:33:19 <rosmaita> well, we could do what nikhil says
14:33:32 <rosmaita> just tell operators to be careful with their policy files
14:33:32 <jokke_> nikhil: I would love to think that way as well, but client defaulting to API v2 proved that to absolutely not being the case
14:33:43 <nikhil> yeah, I find that upgrade notes would do a really good job at what is expected
14:33:47 <bunting> Looking at the operator mailing list, they are in broad favour of at least using admin
14:33:54 <nikhil> this sort of thing is the best candidate for highlights
14:34:39 <tsymanczyk> domany other projects have a hard coded default that overrides the policy.json default?
14:34:43 <nikhil> sigmavirus24: is this worth a backport?
14:35:05 <nikhil> if yes, we can introduce a new policy rule and use that for deactivated images
14:35:26 <nikhil> (not sure, if we need it for mitaka since the feature will be in newton)
14:35:28 <jokke_> nikhil, sigmavirus24: it's backwards incompatible change we really can't backport
14:35:43 <sigmavirus24> (Was catching up) I agree with jokke_
14:35:59 <rosmaita> i agree with jokke_ and sigmavirus24
14:37:46 <nikhil> I would love a review discussion on this, I can't seem to fit all the pieces together atm.
14:37:50 <sigmavirus24> Also not sure we can just switch this on in Newton without a deprecation/warning cycle
14:38:06 <rosmaita> sigmavirus24: that's what i was wondering
14:38:22 * sigmavirus24 had tried to make the policy.json more explicit over a year ago but never got the time to finish it up
14:38:36 <jokke_> sigmavirus24, rosmaita: if we overwrite the default in code to reflect the current behavior, I think we can do it without deprecation
14:38:42 <sigmavirus24> It was also partially worthless because most of our policy is written in Python near the db layer
14:39:12 <sigmavirus24> (because when we added oslo.policy, we basically just added it as a dependency and did almost nothing else with it :()
14:39:56 <rosmaita> sigmavirus24: great ... so this is looking like a bigger and bigger project
14:40:02 <rosmaita> spec time!
14:40:08 <jokke_> :)
14:40:18 <nikhil> rosmaita: thanks
14:40:41 <nikhil> we can start with a lite-spec and if needed go to a full spec
14:40:55 <nikhil> moving on for now
14:41:03 <sigmavirus24> rosmaita: that's just historical griping
14:41:10 <sigmavirus24> But yeah, it's spec worthy
14:41:18 <tsymanczyk> i'm not disagreeing with the idea, but it's going to be confusing to debug from an op perspective with 3 possible sources of policy, one non-standard
14:41:29 <rosmaita> tsymanczyk: ++
14:41:36 <rosmaita> it needs some more thought
14:41:39 <hemanthm> tsymanczyk: ++
14:42:09 <nikhil> yes, overrides need to be carefully introduced
14:42:20 <nikhil> I will come back to abhishek's request later as we've said in the past that meetings should not be used for asking reviews.
14:42:32 <nikhil> #topic Policy concerning changes to "old" db migration scripts. (rosmaita)
14:42:43 <nikhil> #link https://review.openstack.org/#/c/330009/
14:42:53 <rosmaita> ok, there's a bit of disagreement on this topic
14:43:11 <rosmaita> i had thought in the past we didn't modify database scripts unless there was a bug in them
14:43:33 <rosmaita> primarily so that operators don't get confused
14:43:45 <rosmaita> and think there's a bug when it's just a spelling correction
14:44:03 <nikhil> ok, is that the only issue?
14:44:13 <rosmaita> yes, what is our policy about this?
14:44:44 <rosmaita> it's a simple change and i don't mean to hold it up pointlessly
14:44:53 <nikhil> I'd say operator awareness takes precedence over spell correct. so, let's avoid trivial changes on DB scripts and ask people to fix such things as a part of stronger bugs.
14:45:01 <jokke_> I'm with rosmaita on this. I think we should treat those migration scripts with utmost care and not just poke them for comment spelling mistakes
14:45:25 <tsymanczyk> agreed
14:45:33 <hemanthm> rosmaita: I'm not sure what the policy is but I agree with you
14:45:38 <rosmaita> ok, so everyone break out your spell-checker when you review db scripts
14:45:45 <nikhil> :)
14:45:47 <rosmaita> because you only get one chance to get them right!
14:45:52 <jokke_> ++
14:45:53 <tsymanczyk> misspell doesn't hurt anyone
14:46:09 <jokke_> specially when it's in the comments
14:46:26 <jokke_> would be different story if it was spelling mistake on table or column name :P
14:46:31 <rosmaita> ok, i will put up a patch for the contrib docs or somewhere appropriate mentioning this
14:46:36 <nikhil> rosmaita: you can link ref to this meeting note saying that -2 is worthy and okay with other glancers.
14:46:47 <rosmaita> ok, thanks
14:46:53 <hemanthm> it hurts people's OCD sometimes :P
14:47:04 <nikhil> #topic open discussion
14:47:06 <jokke_> nikhil: perhaps agreed tl;dr for the meeting records
14:47:16 <tsymanczyk> exposure therapy
14:47:24 <rosmaita> tsymanczyk: :)
14:47:40 <nikhil> jokke_: sure, ty for reminding
14:48:55 <nikhil> #agreed spell-corrections on DB scripts are forbidden unless you are fixing them as a part of another stronger bug on the migration script itself. Changing migration scripts confuses ops/admins and their preference will be taking precedence over fixing spell errors.
14:49:10 <jokke_> thnx
14:49:24 <sigmavirus24> nikhil: I would augment that with "if the script has not been part of a release yet, they're fair game"
14:49:37 <nikhil> sigmavirus24: totally
14:49:38 <jokke_> sigmavirus24: +
14:49:48 <sigmavirus24> I don't think we should lock down migrations that operators haven't had the chance to use yet
14:49:56 <rosmaita> sigmavirus24: ++
14:50:05 <nikhil> rosmaita: worth adding to contribe doc you if plan to add (or I can).
14:50:27 <nikhil> (all the gotchas to this project-policy)
14:50:36 <rosmaita> nikhil: i'll do it since i stirred up this problem
14:50:41 <nikhil> thanks!
14:51:47 <jokke_> The talk submission page is open for Barcelona
14:51:53 <nikhil> abhishek: for just once, I will let you propose you review request as it's been sitting for a while (this is case by case exclusion to our simple-review-requests-not-in-meeting rule)
14:52:08 <abhishek> hi, sorry for bringing this up in meeting, I was not aware about this
14:52:15 <jokke_> so people lets start planning and sharing ideas for Glane related topics
14:52:56 <rosmaita> jokke_: how about you & me do a "how to work in a cross-cultural environment; or, there's no word for 'please' in Finnish"
14:53:02 <nikhil> abhishek: please take a look at relatively recently added best practices for meeting in the agenda etherpad (near top)
14:53:09 <jokke_> rosmaita: ++ ;)
14:53:18 <hemanthm> rosmaita: lol, is there a culture track?
14:53:26 <rosmaita> i think we should start one!
14:53:26 <nikhil> BoF
14:53:27 <abhishek> nihil: sure,
14:53:52 <rosmaita> jokke_: i am only partially kidding, i think it's worth a thought
14:54:16 <hemanthm> rosmaita: maybe you can also talk about how -1s shouldn't offend people
14:54:18 <jokke_> rosmaita: just sent you a ping around same feeling :D
14:54:30 <rosmaita> hemanthm: ++
14:54:31 <jokke_> hemanthm: nor -2s
14:54:32 <nikhil> just don't have that tied to glance
14:54:39 <rosmaita> nikhil: ++
14:55:17 <nikhil> Return request-id to caller
14:55:31 <nikhil> https://review.openstack.org/#/c/261288/
14:55:32 <nikhil> https://review.openstack.org/#/c/316052/
14:55:48 <hemanthm> jokke_: totally! But getting people to take -1s on their face value is a big win to start with.
14:55:52 <abhishek> need review on these patches
14:55:53 <abhishek> Both are against the same blueprint suggested by different members.
14:55:53 <abhishek> Please review and let me know your opinions about the same
14:56:03 <abhishek> thank you for considering this time
14:57:03 <jokke_> hemanthm: yeap!
14:57:34 <nikhil> Thanks all for joining!
14:57:37 <jokke_> abhishek: those are the logging stuff I commented earlier?
14:58:00 <abhishek> jokke_: no that is different
14:58:19 <abhishek> this solution is suggested by Stuart to use hooks
14:58:20 <jokke_> ah, k
14:58:32 <jokke_> will tryto have a look
14:58:40 <abhishek> jokke_: thank you
14:59:06 <jokke_> thanks all!
14:59:36 <nikhil> #endmeeting