18:01:35 <morganfainberg> #startmeeting Keystone
18:01:36 <openstack> Meeting started Tue Jul 21 18:01:35 2015 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:38 <morganfainberg> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:01:39 <openstack> The meeting name has been set to 'keystone'
18:01:45 * ayoung needs to leave at the 1/2 hour mark
18:01:47 <morganfainberg> Hi everyone!
18:01:49 <lhcheng> o/
18:01:51 <dstanek> o/
18:02:03 <morganfainberg> so... lets jump right in
18:02:03 <ericksonsantos> Hi :)
18:02:08 <morganfainberg> Welcome back from midcycle
18:02:15 <morganfainberg> time to do non-midcycle things now
18:02:19 <morganfainberg> #topic Dynamic Policies
18:02:24 <morganfainberg> ayoung, samueldmq: o/
18:02:28 <ayoung> W00t
18:02:33 <samueldmq> hello guys o/
18:02:33 <ayoung> ok,  gave a presentation last week
18:02:36 <ayoung> link in am oment
18:02:39 <ayoung> moment
18:02:47 <gyee> still digesting them lobstars
18:03:03 <henrynash> (lobsters, plural ????)
18:03:13 <ayoung> #LINK to git repo https://github.com/admiyo/keystone-rbac-presentation
18:03:27 <gyee> henrynash, +2!
18:03:43 <ayoung> #LINK https://github.com/admiyo/keystone-rbac-presentation/raw/master/risk-assessment.pdf
18:04:00 <geoffarnold> +1 (a +2 would just go to his head)
18:04:22 <ayoung> I think we are making progress, but still concerned that most people don't get what we are trying to do here...please ask away if you have any questions
18:04:35 <samueldmq> ayoung: yes, and I'd like to ask for an offical decision on the SFE
18:04:40 <ayoung> the goal is to minimize the amount we depend on the remote services to change
18:05:02 <ayoung> morganfainberg, that is for you to decide, or the TC?
18:05:04 <amakarov> ayoung, we have some Horizon folks here interested to try to make an editor for policies
18:05:06 <samueldmq> ayoung: see what cores (who didn't responded to the email) think and see what morganfainberg thinks (since it's a ptl decision, as ttx said :))
18:05:21 <morganfainberg> ayoung: hmm?
18:05:25 <morganfainberg> ayoung: the SPFE?
18:05:25 <ayoung> put it to a vote?
18:05:27 <geoffarnold> I think we need to develop a crisp strategy that we can share x-project (multi-cycle, inevitably)
18:05:28 <ayoung> yep
18:05:31 <morganfainberg> it's a core decision
18:05:39 <morganfainberg> i'll support the general view of the keystone-core team
18:05:45 <samueldmq> morganfainberg: ++
18:05:50 <henrynash> ayoung: so my view is that IF we limit our selves to making it easier for projects to source their polciy files form keystone (without any fundamental change to policy format, definitions etc.) then I support
18:05:53 <morganfainberg> it's my call,but i'll leave it to the team to decide
18:06:02 <ayoung> geoffarnold, that is the goal;  need to make it understandable cross project
18:06:20 <morganfainberg> i would rather not step on the toes of those who need to review/maintain/support/look at bugs in it [if that makes sense]
18:06:22 <samueldmq> henrynash: I think that's pretty the scope to L, at least as I see it
18:06:30 <ayoung> henrynash, that is exactly the intention of the SFPE
18:06:52 <gyee> ayoung, I am lost, you saying changing the policy format is a precursor to dynamic policy?
18:07:01 <ayoung> gyee, no
18:07:10 <ayoung> no change to the policy format is proposed
18:07:11 <gyee> they are two different deal
18:07:17 <geoffarnold> I'll take the strategy + motivating user stories to the ProductWG when we're ready
18:07:34 <ayoung> samueldmq, can you find the link to the SFPE email?
18:07:47 <ayoung> geoffarnold, those are all in the presentation
18:08:05 <samueldmq> ayoung: henrynash the bp https://blueprints.launchpad.net/keystone/+spec/dynamic-policies-delivery
18:08:20 <morganfainberg> ayoung: if you want a vote, happy to start one
18:08:22 <gyee> yeah those changes are fairly contained
18:08:22 <samueldmq> and the email ...
18:08:24 <samueldmq> #link https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg57416.html
18:08:28 <morganfainberg> otherwise general consensus here works too
18:08:28 <geoffarnold> I know. Waiting on final consensus
18:08:47 <gyee> no objection here
18:08:50 <ayoung> as far as delivery, what we are propsing can be summarized like this
18:09:10 <ayoung> we make use of the endpoint policy extension we have now to associate a policy with an endpoint
18:09:15 <ayoung> endpoints will fetch by endpoint id.
18:09:32 <ayoung> The most explicit will be to set the id in the authtoken secition of the config file
18:09:32 <henrynash> samueldmq: well, at lesat one of this listed is abandoned!
18:09:42 <ayoung> later, we will implement aless invasive approch;
18:09:52 <ayoung> calculate the endpoint_id from the URL
18:09:54 <bknudson> "endpoints will fetch by endpoint id." -- this has to be implemented in all the other projects?
18:10:05 <samueldmq> henrynash: yes, as a consequence of what was decided on the midcycle.. we'll be fetching by endpoint_id, not by policy id
18:10:22 <henrynash> ayoung, samueldmq: before a vote, we need a definitive list of what BPs are included
18:10:26 <bknudson> do you feel like you've incorporated sdague's concerns?
18:10:46 <ayoung> bknudson, "has to" no.  "may be" yes
18:10:46 <henrynash> ayoung, samueldmq: please excluded those you have abandoned
18:10:49 <samueldmq> henrynash: just this one for the dynamic delivery: https://blueprints.launchpad.net/keystone/+spec/dynamic-policies-delivery
18:10:51 <samueldmq> #link https://blueprints.launchpad.net/keystone/+spec/dynamic-policies-delivery
18:10:55 <samueldmq> that's all for L
18:11:08 <samueldmq> henrynash: how do I exclude that ?
18:11:20 <ayoung> samueldmq, edit the white board and remove the abandonded specs, please
18:11:33 <morganfainberg> or say "(abandoned)" next to them
18:11:35 <morganfainberg> same net effect
18:12:41 <samueldmq> ayoung: henrynash done!
18:13:18 <samueldmq> morganfainberg: sorry was removing :) it can be viewed as abandoned when filtering by gerrit topic
18:13:26 <morganfainberg> its' fine either way
18:13:39 <morganfainberg> both work, it indicates what is active
18:14:08 <samueldmq> ayoung: bknudson has a question about sdague's concerns above .. ^
18:14:22 <samueldmq> any other core has any concern/question on this subject?
18:14:24 <stevemar> i'm still super weary about this
18:14:31 <samueldmq> so we can clarify before a vote
18:14:34 <ayoung> no clue on whether sdague would approve or reject at this point...
18:14:46 <geoffarnold> stevemar weary or wary?
18:14:58 <stevemar> wary :P
18:15:01 <ayoung> geoffarnold, he's wary, I'mweary
18:15:15 <samueldmq> stevemar: hehe I need to translate that one :p
18:15:24 <geoffarnold> ayoung, srevemar I knew that ;-)
18:15:48 <ayoung> stevemar, please state your concerns
18:15:56 <gyee> stevemar, do let us know your feelings, this is also a dynamic policy therapy session
18:15:56 <samueldmq> I think we need more love on this subject, what is target to L is very small, the delivery
18:16:08 <samueldmq> let's clear the points that need to, get reviews, and get it done :)
18:16:13 <morganfainberg> gyee: lets save therapy for another time
18:16:28 <bknudson> I know I've had lots of time to look at the spec but I haven't yet... I wouldn't mind taking a look at it this week and then I'll vote on the spec.
18:16:29 <stevemar> a whole system for storage/retrieval of policies to solve the issue of inconsistent 'is_admin' roles seems like overkill
18:16:43 <bknudson> I think people are wary because we implement lots of things that other projects wind up not using
18:16:51 <bknudson> so are other projects actually going to use this?
18:16:59 <geoffarnold> stevemar overkill for this, or overkill as an eventual goal?
18:17:17 <samueldmq> bknudson: other projects don't even need to know about it, they get the policy file
18:17:27 <samueldmq> bknudson: that can be modified before with the dynamic one
18:17:33 <stevemar> geoffarnold: i'd prefer to just better define what is_admin is, and make sure projects adhere to that
18:17:39 * marekd sneaks in late
18:17:41 <samueldmq> bknudson: so no change on other projects for the delivery, if that's what you want to know
18:17:42 <ayoung> policy had a store and fetch mechanism for al ong time, it just was useless
18:17:43 <bknudson> everyone's using oslo.policy and they use that?
18:17:50 <samueldmq> bknudson: yes
18:17:56 * morganfainberg directs marekd to the open seat in the front of the room - no sneaky
18:18:01 <ayoung> bknudson, not all projects have migrated from the incubated yet
18:18:11 <samueldmq> bknudson: that will be optional I guess.. not a must use that
18:18:15 <stevemar> just nova and a few of the new projects
18:18:16 <gyee> this is not really about admin
18:18:23 <gyee> admin is deployment-specific
18:18:30 <geoffarnold> stevemar that's a good short term goal. as we discussed last week, is_admin needs to disappear long term, except for break-glass
18:18:32 <gyee> it just some role with some capabilities
18:18:32 <samueldmq> bknudson: so that goes in the middleware/oslo config sections
18:18:34 <ayoung> stoarge is just the first step.  The goal is to be able to link the polices and the role assignments into a coherent mechanism
18:18:50 <ayoung> so...yeah, each step is going to seem small, cuz, you know, baby steps
18:18:56 <gyee> this is really about flexibility in authorization management
18:18:58 <ayoung> and things that are understandable, and valuable in and of themselves
18:18:59 <bknudson> are you planning to put together a gate job that uses it?
18:19:03 <henrynash> here’s the fundamental question (imho): are the eventual solutions to policy one that require us to recommend that cloud providers top using the tradiational methods of policy distribution (e.g. chef etc.) and instead use keystone as a central repository of policy
18:19:12 <bknudson> changing devstack to use it?
18:19:22 <bknudson> functional tests?
18:19:23 <morganfainberg> henrynash: good question
18:19:24 <bknudson> documentation?
18:19:26 <henrynash> (provuders stop…)
18:19:28 <samueldmq> bknudson: yeah I can do it
18:19:33 <ayoung> bknudson, yes, yes, and yes.
18:20:15 <gyee> henrynash, this is same mechanism as domain backend in sql
18:20:20 <stevemar> could it live as it's own project until all the baby steps are done? or as a feature branch?
18:20:34 <samueldmq> ayoung: see henrynash's question .. if we do that, we are advising them to do so, i.e use keystone for the distribution instead of CMS
18:20:40 <ayoung> stevemar, I'd probably just give up in frustration if we tried
18:20:53 <henrynash> if we think yes to my question, then what is being roposed seems a godo second step (we already mad teh first by having the APIs to allow such a centralized repository)
18:21:12 <morganfainberg> ok 4 more mins on this topic
18:21:28 <morganfainberg> then we either vote or use the spec as the vote
18:21:38 <ayoung> stevemar, its like;  something major is broken here.  Keystone itslef is a security nightmare, and we are afraid of fixing it.  I'm fine with someone suggesting an alternative approach tio fixing it, but not with postponing the fixes
18:21:53 <geoffarnold> +1
18:22:00 <ayoung> things take for-ever in Keystone, and if we say "we are afraid of this"  we will never fix it
18:22:11 <ayoung> so...speak up.  how do we fix keystone?
18:22:34 <morganfainberg> ayoung: this, however, is *not* a keystone is a security nightmare. this is a policy is a security nightmare
18:22:43 <dstanek> I like the idea of a separate branch/repo for this to prove it out
18:22:45 <morganfainberg> we can fix keystone policy - that really is a lot less difficult
18:22:45 <gyee> a quick hack would be to patchup the individual policy.json file :)
18:22:47 <gyee> just saying
18:22:54 <gyee> if we only care about the admin problem
18:22:57 <morganfainberg> fixing policy everywhere is hard
18:23:02 <ayoung> morganfainberg, can we?  PLease explain how.
18:23:40 <ayoung> gyee, if I thought we could address this by fixing the individual policy files, I'd go for it
18:23:41 <morganfainberg> ayoung: simple - we change the loading params, make a new default, change devstack, and tell people the old single admin/member policy is dead with a simple migration to a "real" policy. that isn't hard to sell
18:23:48 <morganfainberg> ayoung: fixing is_admin *everywhere* is hard
18:23:55 <stevemar> ayoung: if it were a nightmare we'd have operators desperately asking us for it. i'm hearing a "yeah, it's cool"
18:24:04 <geoffarnold> fixing policy everywhere is hard, but it's less hard if we provide an easy-to-adopt framework which addresses the issues
18:24:11 <gyee> ayoung, like defining a nova_admin role?
18:24:39 <morganfainberg> just trying to avoid the "keystone is broken" statements, keystone is mildly broken - but it's hard to fix everything everywhere - we know this.
18:24:42 <ayoung> gyee, namespaced roles have been suggested before...are you saying we should prioritize that?
18:25:18 <gyee> ayoung, we could
18:25:22 <gyee> but that's not "dynamic"
18:25:31 <gyee> but would get us pass the global admin problem
18:25:39 <henrynash> ayoung: gyee is suggesting somthig simpler I think, jsut work with the prpjects so the don’t call their “own” admin role “admin”
18:25:51 <lbragstad> henrynash: ++
18:25:53 <ayoung> henrynash, who gets to assigne that role?
18:25:57 <ayoung> what scope is it enforced on?
18:26:11 <ayoung> and how is that enforcement done?
18:26:14 <gyee> enforcement is still the same
18:26:37 <ayoung> gyee, and that is policy, right?
18:26:39 <morganfainberg> ok since ayoung needs to go in 4...
18:26:44 <henrynash> ayoung: and second, we change oslo.policy so we can put comments in policy.json, create some kick-ass samples (e.g. give one to Nova and Glance to show them how)
18:26:44 <stevemar> also, oslo.policy is already dynamic, edit a file and the next request will use it
18:26:48 <gyee> is_admin: role:admin or role:nova_admin
18:26:59 <ayoung> gyee, it needs to be scoped
18:27:04 <morganfainberg> are we voting on the spfe? or are we aiming for a different tack (get namespaced roles?)?
18:27:12 <morganfainberg> oor using the spec as a vote?
18:27:16 <gyee> just assign the nova_admin role to user for a given project
18:27:45 <morganfainberg> or something totally different?
18:28:05 <ayoung> We can distribute the mechanism by some other form.  The  problem is then it becomes "config"
18:28:08 <ayoung> and not "data"
18:28:09 <geoffarnold> the state of this discussion (and last week) suggests that whatever we're talking about it isn't ready for a vote yet
18:28:11 <samueldmq> morganfainberg: I think we should vote.. if we don't get enough yeses, that may mean we should reprioritize, or try anythingelse ?
18:28:13 <ayoung> and the rules change for the operators.
18:28:13 <geoffarnold> so just spfe
18:28:17 <gyee> to maintain backward compatibility, we roll a small middleware to translate nova_admin to admin at nova api pipeline
18:28:37 <ayoung> gyee, gah!
18:28:38 <ayoung> no
18:28:51 <morganfainberg> ayoung: your call since it's your initiative - vote, defer, something else?
18:28:55 <henrynash> gyee: no (even from me!)
18:28:56 <ayoung> vote
18:29:00 <morganfainberg> ok
18:29:03 <gyee> like I said, that's a simple hack to solve the global adminness issue
18:29:04 <ayoung> just on the distro mechanism
18:29:07 <gyee> but not for dynamic policy
18:29:13 <ayoung> it is opt in...won;'t be enabled until the user wants it
18:29:27 <ayoung> specifically
18:29:29 <ayoung> https://review.openstack.org/#/c/134655/
18:29:30 <ayoung> and
18:29:36 <henrynash> ayoung: is this classed as experimental?
18:29:36 <ayoung> https://review.openstack.org/#/c/197980/
18:29:38 <morganfainberg> #startvote Dynamic Policy SPFE Acceptance? accept, deny, defer
18:29:39 <openstack> Begin voting on: Dynamic Policy SPFE Acceptance? Valid vote options are accept, deny, defer.
18:29:40 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:29:50 <bknudson> #vote defer
18:30:08 <gyee> #vote accept
18:30:08 <morganfainberg> defer would be either next meeting or use spec scoring as the vote
18:30:10 <ayoung> henrynash, so one is cahce headers...I see no need to defer or make experimental
18:30:19 <ayoung> the other is for middleware
18:30:22 <breton> #vote defer
18:30:27 <ayoung> #vote accept
18:30:43 <amakarov> #vote defer
18:30:47 <samueldmq> #vote accept
18:30:57 <ayoung> https://review.openstack.org/#/c/134655/  is the thing we are really voting on....the other is just better HTTP coding
18:31:05 * morganfainberg pokes stevemar
18:31:06 <henrynash> #vote accept
18:31:08 <samueldmq> morganfainberg: if we defer, people should put more love on that, we'll be defering because they don't know enough about it
18:31:15 <geoffarnold> (this is just cores, right?)
18:31:20 <stevemar> morganfainberg: i'm thinking
18:31:21 <morganfainberg> geoffarnold: feel free to vote
18:31:29 <stevemar> #vote defer
18:31:30 <gyee> geoffarnold, this is democracy
18:31:32 <morganfainberg> geoffarnold: i'll weight to cores if it's a tie
18:31:37 <geoffarnold> #vote accept
18:31:39 <marekd> #vote accept
18:31:53 <lbragstad> #vote defer
18:31:58 <ayoung> so, before we close the vote, let's be clear on what we are voting on
18:32:20 <ayoung> a defer vote means we will make no progress on dynamic policy this release
18:32:38 <gyee> #vote for progress
18:32:38 <openstack> gyee: for progress is not a valid option. Valid options are accept, deny, defer.
18:32:43 <breton> > defer would be either next meeting or use spec scoring as the vote
18:32:46 <dstanek> #vote defer
18:32:49 <ayoung> this was the absolute smallest piece of it we could make happen.
18:33:13 <morganfainberg> #votes
18:33:23 <morganfainberg> #votestatus
18:33:28 * morganfainberg cant remember
18:33:30 <samueldmq> #showvote
18:33:31 <openstack> defer (6): lbragstad, bknudson, dstanek, amakarov, breton, stevemar
18:33:32 <openstack> accept (6): gyee, ayoung, marekd, geoffarnold, samueldmq, henrynash
18:33:33 <gyee> endvote first
18:33:54 <samueldmq> morganfainberg: ^ showvote ;)
18:34:06 <morganfainberg> crap...
18:34:12 <morganfainberg> really i'm going to have to be the tie breaker?
18:34:14 <bknudson> it's up to morganfainberg
18:34:16 <morganfainberg> *really*?!
18:34:17 <gyee> hah
18:34:22 <breton> ok, love me now
18:34:27 <breton> #vote accept
18:34:29 <bknudson> nobody voted no, so I'm fine with it either way
18:34:43 <gyee> breton, heh
18:34:49 <morganfainberg> where is lbragstad, dolphm, and jamielennox?
18:34:49 <bknudson> the only way it could go is towards accept at this point
18:34:56 <lbragstad> I already voted
18:34:59 <marekd> morganfainberg: lbragstad voted
18:35:06 <lbragstad> \o/
18:35:07 <morganfainberg> oh
18:35:08 <morganfainberg> haha
18:35:12 <ayoung> jamielennox is probably asleep.  He's been battling SSL issues until the wee hours of the morning
18:35:16 <gyee> lbragstad, hi
18:35:23 <ayoung> I need to go
18:35:24 <morganfainberg> and even split of cores also
18:35:25 <morganfainberg> ugh
18:35:27 <dolphm> morganfainberg: o/
18:35:27 <bknudson> switch to TLS
18:35:32 <geoffarnold> #showvote
18:35:32 <openstack> defer (5): lbragstad, bknudson, dstanek, amakarov, stevemar
18:35:33 <openstack> accept (7): gyee, ayoung, marekd, geoffarnold, samueldmq, henrynash, breton
18:35:38 <morganfainberg> dolphm: ^^ vote - and views?
18:35:45 <dolphm> oh crap meeting lol
18:35:47 * morganfainberg is trying to *not* be the tie breakers here
18:36:10 <dolphm> #vote defer
18:36:15 <ayoung> I'll check the results later
18:36:22 <morganfainberg> ahha
18:36:42 <morganfainberg> #vote defer
18:36:53 <morganfainberg> #endvote
18:36:53 <openstack> Voted on "Dynamic Policy SPFE Acceptance?" Results are
18:36:54 <openstack> defer (7): lbragstad, morganfainberg, bknudson, dstanek, dolphm, amakarov, stevemar
18:36:55 <openstack> accept (7): gyee, ayoung, marekd, geoffarnold, samueldmq, henrynash, breton
18:37:07 <bknudson> this is impossible
18:37:13 <morganfainberg> even split - but more cores on defer
18:37:19 <morganfainberg> so we will go with defer.
18:37:21 <samueldmq> morganfainberg: next meeting ? so we can vote again even if people don't look at the specs
18:37:27 <morganfainberg> please vote on the spec - score it
18:37:45 <morganfainberg> #action Keystone Cores - review the SPFE and Dynamic policy spec(s) specifically for liberty
18:37:58 <morganfainberg> i expect to have scores on the specs by next meeting
18:38:21 <morganfainberg> if you don't... we'll approve it and you're stuck with it
18:38:32 <morganfainberg> since defer is closer to accept than deny
18:39:00 <morganfainberg> ok moving on
18:39:04 <morganfainberg> #topic Moving role assignment inheritance (OS-INHERIT) to core
18:39:08 <morganfainberg> henrynash: o/
18:39:17 <henrynash> ok, so a spec for this is here:  https://review.openstack.org/#/c/200434/
18:39:22 <henrynash> #link  https://review.openstack.org/#/c/200434/
18:40:33 <morganfainberg> fwiw - I'm for this.
18:40:40 <bknudson> I think we agreed we're moving things from extensions already
18:40:41 <henrynash> Liek to get people’s views on pushing this in….as I say, the only wrinke is using the change of API (i.e. extension -> core) to provide new inheritance rules (that we think are mosre suitable to generalized project hierachies)
18:40:58 <morganfainberg> bknudson: this is the API change to change how inheritence works we're considering when moving
18:41:05 <morganfainberg> bknudson: since it wont be OS-INHERIT anymore
18:41:24 <bknudson> has to be deprecated
18:41:28 <bknudson> then we can remove it in v4
18:41:30 <morganfainberg> OS-INHERIT will maintain the old and be deprecated
18:41:32 <morganfainberg> yes
18:41:39 <henrynash> bknudson: the old OS-INHERIT will depreacted, but support for 4 cycles in case anyone wants the old sematics
18:41:44 <morganfainberg> but the non-deprecated/new way will be the new inheritence model
18:41:59 <morganfainberg> henrynash: at least 4.. we may not remove before v4
18:42:09 * morganfainberg kicks that can waaaaay down the line
18:42:12 <henrynash> morganfainberg: agreed
18:42:28 <morganfainberg> if there are concerns about this change - please say so now.
18:42:44 <bknudson> I haven't looked at all the changes but can't think of a reason to not do it.
18:42:54 <gyee> same here
18:42:58 <gyee> defer to next week :)
18:43:06 <geoffarnold> no concerns
18:43:06 <morganfainberg> gyee: no defer
18:43:08 <morganfainberg> sorry
18:43:11 <dstanek> I only browsed the change, but it looked OK
18:43:12 <morganfainberg> this one is a yes or no
18:43:56 <morganfainberg> #startvote Accept SPFE for os-inherit behavior change when moved to core (old API/behavior deprecated)? yes, no
18:43:56 <samueldmq> henrynash: just a question
18:43:57 <openstack> Begin voting on: Accept SPFE for os-inherit behavior change when moved to core (old API/behavior deprecated)? Valid vote options are yes, no.
18:43:59 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:44:04 <morganfainberg> #vote yes
18:44:11 <samueldmq> henrynash: so we'll be proposing a new inheritance api ?
18:44:17 <gyee> only think I don't like is "GET /projects/{project_id)/groups/{group_id}/roles/inherited"
18:44:22 <samueldmq> henrynash: or just moving the old one ?
18:44:22 <bknudson> #vote yes
18:44:22 <morganfainberg> samueldmq: it'll be rolled into assignment directly
18:44:27 <raildo> #vote yes
18:44:29 <geoffarnold> #vote yes
18:44:31 <marekd> #vote yes
18:44:39 <htruta> #vote yes
18:44:41 <lbragstad> #vote yes
18:44:43 <morganfainberg> samueldmq: OS-INHERIT will be deprecated, but continue on
18:44:44 <dstanek> #vote yes
18:44:47 <morganfainberg> same behavior
18:44:58 <morganfainberg> #showvote
18:44:58 <openstack> yes (8): lbragstad, morganfainberg, bknudson, marekd, geoffarnold, dstanek, htruta, raildo
18:44:59 <samueldmq> I was just thinking about fixing the beharvior of inherited in the new api
18:45:01 <lhcheng> #vote yes
18:45:02 <samueldmq> like
18:45:06 <samueldmq> applying to the node itself
18:45:07 <morganfainberg> samueldmq: can't change behavior
18:45:12 <henrynash> samueldmq: that’s what we are doing!
18:45:13 <morganfainberg> in the old api
18:45:21 <samueldmq> morganfainberg: k but we can in the new
18:45:23 <samueldmq> henrynash: ^
18:45:26 <samueldmq> ?
18:45:30 <morganfainberg> samueldmq: yes and that is the plan :)
18:45:35 <samueldmq> #vote YES
18:45:40 <morganfainberg> 3
18:45:42 <morganfainberg> ...
18:45:43 <morganfainberg> 2
18:45:45 <morganfainberg> ...
18:45:47 <morganfainberg> 1
18:45:48 <morganfainberg> ...
18:45:52 <morganfainberg> #endvote
18:45:53 <openstack> Voted on "Accept SPFE for os-inherit behavior change when moved to core (old API/behavior deprecated)?" Results are
18:45:54 <openstack> yes (10): lbragstad, morganfainberg, lhcheng, bknudson, marekd, geoffarnold, dstanek, htruta, samueldmq, raildo
18:46:00 <morganfainberg> henrynash: have at.
18:46:04 <henrynash> ok!
18:46:12 <morganfainberg> please reference this meeting irc-log in the bp
18:46:24 <henrynash> will do
18:46:26 <morganfainberg> next topic
18:46:29 <morganfainberg> #topic  Clarifying how domain_id, parent_id and is_domain are used in project hierarchies
18:46:32 <morganfainberg> henrynash: you again
18:46:49 <morganfainberg> this should also be quick
18:46:52 <henrynash> ok, so this is mainly clarifying in teh API spec how we use these three things
18:46:54 <henrynash> https://review.openstack.org/#/c/200624/
18:47:03 <henrynash> teh wrinle in this one...
18:47:27 * morganfainberg is fine with this one.
18:47:34 <henrynash> …is that it clarifies that you can use parent_id on proejct creation to implicitely place the project in the hierarchy and hence what domain it is on
18:47:42 <henrynash> (it is in)
18:48:00 <bknudson> cool
18:48:05 <morganfainberg> big +2
18:48:18 <htruta> we're making domain_id optional
18:48:43 <morganfainberg> htruta: only if you provide a parent_id
18:48:51 <morganfainberg> since a parent_id implies a domain_id
18:48:55 <samueldmq> morganfainberg: ++
18:49:07 <morganfainberg> minor usability improvement
18:49:13 <henrynash> yep
18:49:14 <morganfainberg> and doesn't break any api compat
18:49:17 <htruta> what should happen if we pass domain_id but no parent?
18:49:30 <morganfainberg> htruta: ends up as a child of that domain
18:49:36 <morganfainberg> parent_id = domain there
18:49:41 <henrynash> htruta: then the project is placed as a child of the project acting as that domain
18:49:57 <htruta> henrynash, morganfainberg... ok
18:50:02 <htruta> makes sense
18:50:26 <morganfainberg> any concerns?
18:50:54 <htruta> morganfainberg: I'm fine with this
18:50:54 <morganfainberg> please review the spec and score/approve/etc
18:51:15 <morganfainberg> next topic
18:51:19 <morganfainberg> #topic Making project.domain_id immutable
18:51:30 <morganfainberg> isn't this already the case?
18:51:38 <morganfainberg> i mean defaults to be this way
18:51:41 <htruta> just following this structure, we might not be able to change domain_id
18:51:41 <morganfainberg> ??
18:51:44 <bknudson> I think it's an option
18:51:51 <morganfainberg> bknudson: yeah its an option
18:51:54 <morganfainberg> but we default to immutable
18:52:10 <henrynash> morganfainberg: not sure about that, since we used to allow it!
18:52:17 <morganfainberg> and if anyone complains about security by toggling that i'm going to snicker and tell them to stop allowing it
18:52:19 <htruta> I guess the default value is True
18:52:30 <htruta> I think we can't allow change domain_id at all
18:52:31 <morganfainberg> htruta: yeah it defaults to immutable
18:52:34 <htruta> for projects
18:52:41 <morganfainberg> htruta: we're going to need to leave the option
18:52:47 <htruta> once we'll be always changing the parent_id
18:52:54 <geoffarnold> what are the consequences of being not immutable?
18:52:57 <htruta> might break somethings in the hierarchy
18:52:57 <bknudson> we can deprecate mutable.
18:53:04 <morganfainberg> but if anyone says "i did this" i'm going to point them at the CVE
18:53:10 <morganfainberg> that we closed with that option
18:53:15 <morganfainberg> bknudson: ++ we should deprecate the option for removal
18:53:27 <morganfainberg> see who complains.
18:53:31 <raildo> geoffarnold: we probably will have problems with nested quotas, or something like that
18:53:32 <morganfainberg> i don't think *anyone* uses that option
18:53:41 <htruta> geoffarnold: in HMT, we converged to a consensus, where we decided not to change the parent_id of a project
18:53:43 <morganfainberg> raildo: not only that lots of security issues
18:53:54 <raildo> morganfainberg: ++
18:54:01 <morganfainberg> it's why we made it an option and broke API compat to close the gap [default to immutable][
18:54:04 <geoffarnold> thanks
18:54:14 <htruta> morganfainberg, the option is for proejcts, users and groups
18:54:26 <htruta> my intention was only making it immutable to projects
18:54:31 <morganfainberg> htruta: we should deprecate the option for removal across the board
18:54:42 <morganfainberg> don't remove it, just do the deprecate_for_removal=True
18:55:09 <htruta> morganfainberg: no sure if I get your point
18:55:09 <morganfainberg> we can remove it down the line
18:55:27 <morganfainberg> htruta: look at the options in keystone.common.config, there is an option you can pass to it
18:55:34 <morganfainberg> htruta: it marks the option as deprecated for removal
18:55:55 <morganfainberg> htruta: we will deprecate this option across the board - it really is a security risk to have anyone enble it
18:56:11 <henrynash> htruta: to protect the hierarchy, we could error if someone tries to chaneg the domain for a project that is anyting more than a 2 level hierarchy (i.e. domain-.project)
18:56:16 <bknudson> if it should be immutable then there should also be a warning if it is mutable.
18:56:21 <morganfainberg> if someone does enable it and gets pwnd, my answer will be to say "didn't you read the help? it says this is a massive security hole"
18:56:31 <htruta> bknudson: ++
18:56:33 <morganfainberg> bknudson: fair enough
18:57:05 <morganfainberg> htruta: so in short - yeah i'm fine with moving towards truly immutable domain_id across the board
18:57:25 <geoffarnold> +1
18:57:26 <morganfainberg> sounds like we also need a warning added if that option is flipped from default
18:57:36 <bknudson> if there was some situation where we wanted to not support renaming in whatever situation then that would be fine with me.
18:57:56 <bknudson> "renaming" -> "changing domain"
18:58:02 <morganfainberg> bknudson: ++
18:58:03 <htruta> morganfainberg: do you plan to make it immutable to users and groups as well?
18:58:19 <morganfainberg> htruta: yes please do it across the board with your change
18:58:22 <gyee> renaming should be allowed
18:58:34 <morganfainberg> gyee: change_domain_id of <resource>
18:58:39 <morganfainberg> not "rename"
18:58:40 <morganfainberg> :)
18:58:42 <gyee> no
18:58:43 <gyee> ah
18:58:52 <htruta> morganfainberg: ok
18:58:57 <htruta> do we need a spec?
18:58:59 <geoffarnold> 1 min
18:59:18 <bknudson> bp or wishlist bug would be fine
18:59:18 <morganfainberg> htruta: should be a very simple change - mark option as deprecated for removal, make sure we have a warning if it is toggled
18:59:24 <morganfainberg> htruta: wishlist bug please
18:59:38 <htruta> morganfainberg, bknudson: cool
18:59:48 <morganfainberg> and we're done
18:59:51 <morganfainberg> #endmeeting