18:04:48 <morganfainberg> #startmeeting keystone
18:04:49 <openstack> Meeting started Tue Apr  7 18:04:48 2015 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:04:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:04:51 <lbragstad> gyee: ++ fact
18:04:53 <openstack> The meeting name has been set to 'keystone'
18:05:05 <morganfainberg> Hi everyone!
18:05:11 <bknudson> hi
18:05:20 <tmcpeak> heya
18:05:28 <morganfainberg> #topic house keeping
18:05:32 <henrynash> (thinks….who’s handle is everyone….)
18:05:41 <morganfainberg> Few quick items.
18:05:50 <morganfainberg> lhcheng: you here?
18:06:05 <lhcheng> morganfainberg: yes!
18:07:07 <morganfainberg> So, based on great reviews and feedback, I want to introduce lhcheng as the newest member of the core reviewer team.
18:07:25 <gyee> ++
18:07:26 <bknudson> great!
18:07:27 <lbragstad> lhcheng: congrats!
18:07:28 <ayoung> Rock on!
18:07:29 <stevemar> oh snap! ++
18:07:32 <rodrigods> ++ lhcheng nice!
18:07:36 <lhcheng> morganfainberg: thank you! will do my best to help the team!
18:07:43 <topol> CONGRATULATIONS lhcheng! Very well deserved!
18:07:50 <henrynash> seconded
18:07:53 <jamielennox> congrats lhcheng
18:08:07 <samueldmq> lhcheng, congrats :)
18:08:14 <lhcheng> thanks everyone!
18:08:16 <morganfainberg> Ill be granting him the +2 powers post meeting.
18:08:46 <stevemar> yay
18:08:48 <morganfainberg> We will be looking to continue to grow the core team (if I'm still ptl) next cycle. This is to ensure we have bandwidth to both write code and review.
18:09:03 <morganfainberg> Which is the next house keeping topic.
18:09:32 <morganfainberg> If you want to be PTL, please don't hesitate to run. Send the candidacy email while the window is open.
18:09:56 <morganfainberg> Ok lots to cover today so...
18:10:00 * stevemar thinks morganfainberg should apply for a 4 year term
18:10:09 <morganfainberg> #topic Bandit Progress
18:10:16 <morganfainberg> bknudson: o/
18:10:27 <bknudson> the infra change merged so you can do check experimental
18:10:38 <bknudson> to get a bandit run (along with other junk)
18:10:42 <bknudson> so there's example results:
18:10:46 <ayoung> morganfainberg, the problem is, you are running,  and no one wants the job.  If you want to encourage lots of people to run for PTL, you need to convince me to run.  Then everyone else will run just to say "There but for the grace of ..."
18:10:59 <bknudson> http://logs.openstack.org/47/170547/1/experimental/gate-keystone-tox-bandit/d054186/console.html -- passes
18:11:09 <bknudson> oops, that one is a failure
18:11:19 <bknudson> http://logs.openstack.org/30/157930/6/experimental/gate-keystone-tox-bandit/3674425/console.html -- is an example of a passing bandit run
18:11:48 <bknudson> so, wanted to find out if anybody has anything else they want to see experimented with.
18:12:10 <bknudson> and if not, we can continue on and have bandit run in the check non-voting.
18:12:16 <lbragstad> bknudson: do we have any lp bugs open for bandit inconsistencies?
18:12:37 <bknudson> lbragstad: what do you mean? keystone passes all bandit checks now.
18:12:40 <tmcpeak> #link https://launchpad.net/bandit
18:12:42 <dolphm> lbragstad: you mean against bandit or keystone?
18:12:57 <tmcpeak> that's our Bandit launchpad, there aren't any major bugs currently open
18:12:58 <lbragstad> bknudson: I meant against Keystone, but you answered my question
18:13:18 <david8hu> lhcheng: congrats!
18:13:29 <bknudson> the reason it fails in http://logs.openstack.org/47/170547/1/experimental/gate-keystone-tox-bandit/d054186/console.html  is because I add code that I knew wouldn't pass.
18:15:07 <stevemar> bknudson, do the docs have examples that would cause it to fail?
18:15:49 <bknudson> stevemar: good question... I haven't looked at the docs... maybe tmcpeak can answer?
18:16:10 <tmcpeak> stevemar: you're asking if the Bandit docs have examples of code that would be caught?
18:16:16 <stevemar> tmcpeak, yeah
18:16:42 <stevemar> theres a bit here https://github.com/stackforge/bandit/tree/master/docs
18:16:55 <tmcpeak> I don't believe so, the Bandit docs haven't seen much love lately..
18:17:03 <stevemar> i'm just thinking if there is a patch that is failing bandit, how do i figure out why it's failing
18:17:09 <stevemar> aside from bugging you or bknudson
18:17:30 <bknudson> The example here shows what bandit prints out: http://logs.openstack.org/47/170547/1/experimental/gate-keystone-tox-bandit/d054186/console.html#_2015-04-03_16_10_23_056
18:17:33 <tmcpeak> the results are pretty self explanatory and show the exact code that triggers the issue
18:17:38 <bknudson> e.g.,  subprocess call with shell=True identified, security issue.
18:17:52 <bknudson> which isn't the most descriptive...
18:18:03 <stevemar> showing the code definitely helps
18:18:10 <bknudson> there was a sprint at the ossg meetup to get some docs together.
18:18:12 <tmcpeak> we have it in our backlog to build better docs and explanations
18:18:14 <stevemar> but i guess we can improve that as we go along
18:18:37 <tmcpeak> eventually we will integrate with these: https://github.com/openstack-security/Developer-Guidance
18:19:16 <bknudson> so https://github.com/openstack-security/Developer-Guidance/blob/master/shell_injection.md#subprocess-shell-injection
18:19:27 <bknudson> is what that subprocess error should point to.
18:19:30 <stevemar> looks like it checks for quite a few things: https://github.com/stackforge/bandit/tree/master/bandit/plugins
18:19:49 <tmcpeak> stevemar: some of the tests are very noisy and have been disabled for the Keystone profile
18:20:06 <tmcpeak> the idea here is to not generate false positives
18:20:11 <tmcpeak> so that people don't learn to ignore the gate
18:20:17 <stevemar> gotcha
18:20:32 <stevemar> okay, i'm all out of questions!
18:20:33 <bknudson> I was thinking it's non-voting for now...
18:20:40 <bknudson> not sure what it's going to take to make it voting.
18:20:43 <tmcpeak> bknudson: +1
18:20:51 <bknudson> probably should at least see a few releases to make sure it's not breaking us.
18:21:06 <tmcpeak> in the mean time, maybe before you guys give the final +2, you can make sure Bandit test passes?
18:21:08 <morganfainberg> lets see the results from non-voting
18:21:15 <morganfainberg> and we can make adjustments before we make it voting
18:21:29 <stevemar> a few releases?! that seems overly cautious
18:21:30 <morganfainberg> please keep eyes on bandit
18:21:40 <bknudson> I'm hoping that people will consider a failing bandit a reason to think twice, for my sake.
18:21:46 <tmcpeak> :)
18:21:46 <morganfainberg> we can evaluate it during Liberty
18:21:51 <stevemar> ++
18:21:54 <morganfainberg> at each milestone
18:21:54 * bknudson is tired of security vulnerabilities.
18:21:59 <morganfainberg> if we are happy we can make it vote
18:22:02 <morganfainberg> if we aren't we defer
18:22:05 <morganfainberg> easy
18:22:06 <bknudson> I meant a few releases of bandit.
18:22:13 <stevemar> bknudson, ah okay
18:22:14 <tmcpeak> morganfainberg: +1
18:22:45 <stevemar> morganfainberg, next?
18:22:57 <morganfainberg> ok
18:23:04 <morganfainberg> #topic RC1 [Kilo Edition]
18:23:07 <tmcpeak> thanks all
18:23:25 <morganfainberg> RC1 patch is gating https://review.openstack.org/#/c/171260/
18:23:34 <morganfainberg> once that lands, liberty is open for development
18:23:44 <bknudson> you going to go through and remove -2s?
18:23:50 <morganfainberg> this means we have 3 major focuses (in order of priority)
18:23:53 <morganfainberg> once that lands
18:23:56 <morganfainberg> bknudson, yes i will
18:24:23 <morganfainberg> 1: RC bugs. Triage bugs. every day.
18:24:33 <morganfainberg> if you see a bug that could be a showstopper tag it rc potential
18:24:38 <morganfainberg> bring it to my attention
18:24:55 <morganfainberg> lets hope we don't have any of those this time (wishful thinking I'm sure)
18:25:01 <morganfainberg> 2: Middleware and KSC bugs/fixes
18:25:25 <morganfainberg> we will do a ksc/middleware cut soon™ that will coincide with the named release
18:25:34 <morganfainberg> this will be used as the basis for gating for stable/kilo afaik
18:25:39 <morganfainberg> and 3: Liberty specs
18:25:46 <morganfainberg> get them posted and reviewed.
18:25:59 <morganfainberg> i would like to have what we do at the midcycle mostly happen at the summit
18:26:10 <morganfainberg> so we have more time to work on getting everything into keystone for Liberty
18:26:22 <morganfainberg> which... is a slightly shorter cycle than kilo has been afaik
18:26:33 <morganfainberg> any questions? thoughts? concerns?
18:26:40 <henrynash> morganfainberg: I think you missed the item on https://review.openstack.org/#/c/142472/12 (I put it at h
18:26:41 <bknudson> how do you get a fix into rc?
18:26:44 <ayoung> need to push for a DOA release, too
18:26:46 <henrynash> oops sorry
18:26:52 <ayoung> we don't get webSSO without it
18:27:04 <bknudson> is there a stable/ branch?
18:27:04 <morganfainberg> bknudson, we flag a bug, bring it up to TTX and we merge to master then backport to the RC branch
18:27:08 <rodrigods> the next topic (assignment inheritance) should be a rc-potential IMO
18:27:09 <rodrigods> :)
18:27:09 <morganfainberg> bknudson, same as last cycle
18:27:12 <stevemar> i think enough things got bumped from kilo that liberty should be pretty full now
18:27:50 <bknudson> we going to add a bunch of migrations?
18:27:55 <morganfainberg> bknudson, yep
18:28:01 <morganfainberg> bknudson, we will add backport placeholders
18:28:03 <bknudson> that happens at the beginning, I think.
18:28:22 <morganfainberg> bknudson, that happens in liberty not in kilo rc though
18:28:29 <bknudson> could update man pages... forgot to do that.
18:28:38 <morganfainberg> bknudson, i expect an RC2
18:28:41 <morganfainberg> we need a sample config update anyway
18:28:47 <morganfainberg> so, lets plan that for RC2
18:28:51 <lhcheng> ayoung: we should be able to release DOA shortly after Horizon completes RC1
18:29:15 <ayoung> lhcheng, ++
18:29:34 <topol> lhcheng awesome
18:29:47 <morganfainberg> henrynash, i was going to defer that to it's own topic btw
18:29:57 <morganfainberg> henrynash, not just lumped into RC meeting topic
18:29:57 <henrynash> morganfainberg: np
18:30:13 <ayoung> Which leads me to a happy announcement.  I have a second Federated/WebSSO mechanism deployed without any code changes.
18:30:19 <dolphm> morganfainberg: how out of date is the current sample config?
18:30:32 <morganfainberg> dolphm, a couple weeks at most
18:30:33 <rodrigods> ayoung, ++
18:30:35 <rodrigods> nice
18:30:38 <ayoung> So..good work you guys on making that spec flexible
18:30:40 <morganfainberg> dolphm, and possibly not at all
18:30:48 <dolphm> cool
18:30:58 <morganfainberg> dolphm, but we have man page update to do. so we'll make sure sample for RC is up-to-date for an RC2
18:31:02 <morganfainberg> :)
18:31:03 <bknudson> the keystone-manage man page is missing all the fernet stuff
18:31:07 <stevemar> ayoung, yay!
18:31:12 <stevemar> topol, ^
18:31:20 <dolphm> bknudson: file a bug!
18:31:20 <lbragstad> bknudson: I can make a point to update that
18:31:40 <stevemar> morganfainberg, the sample config shouldn't need change ... i think...
18:31:46 <morganfainberg> in short everyone did an awesome job in kilo
18:31:53 <morganfainberg> thanks for all your hard work
18:32:24 <morganfainberg> lets make liberty even better :)
18:32:30 <bknudson> lbragstad: https://bugs.launchpad.net/keystone/+bug/1441300 <-- dolphm
18:32:31 <openstack> Launchpad bug 1441300 in Keystone "keystone-manage man page updates" [Undecided,New]
18:32:43 <morganfainberg> bknudson, tag to kilo please specifically
18:32:51 <morganfainberg> or i can
18:33:01 <morganfainberg> #topic Adding inherited column to PK patch
18:33:10 <morganfainberg> henrynash, samueldmq, ayoung, o/
18:33:17 <morganfainberg> so this potentially can be added to RC2
18:33:19 <henrynash> ok, let me just set the scene
18:33:25 <morganfainberg> as an FYI
18:33:27 <morganfainberg> it wont be in RC1
18:33:29 <ayoung> yeah, lets not do that.  The field is...
18:33:49 <ayoung> inherited | tinyint(1)
18:33:56 <henrynash> this is a bug to make teh code do what the original design/spec intended
18:33:57 <topol> Ayoung, good job on the SSO
18:34:01 <morganfainberg> anyway i'll let henrynash and the like discuss the state and then determine if it goes into RC
18:34:04 <ayoung> topol, thanks
18:34:18 <ayoung> this should be ported to an enum like the "type" field
18:34:31 <henrynash> #link https://review.openstack.org/#/c/142472/
18:34:37 <ayoung> type is a crappuy name, BTW....
18:34:43 <rodrigods> this should really be in RC2
18:34:54 <samueldmq> ayoung, wait, people need context :) think henrynash is doing so
18:35:06 <henrynash> when this was first proposed, we ahd a lot of discussion about whether assignments (taht are inherited)...
18:35:17 <dolphm> morganfainberg: why not RC1? (what's in RC1?)
18:35:18 <henrynash> …should be on the domain, or just on the chikdren of the domain
18:35:52 <henrynash> and indeed whether you should be able to specify wehther you wanted both of these to happen when you made teh assignment
18:36:04 <morganfainberg> dolphm, the question is if this should land in kilo at all
18:36:19 <morganfainberg> dolphm, so i didn't include this in RC
18:36:38 <morganfainberg> dolphm, if it *should* land in kilo, since we will likely have an rc2, we can include it
18:36:40 <bknudson> this change would be difficult to backport due to a schema migration...
18:36:49 <henrynash> this was rejected during the design cycle for this (back in Grizzly?) and it was recommended that we keep them very separate…an assignment is either on an object, or it is on teh chikdern of the object
18:37:00 <morganfainberg> bknudson, idempotent schema changes aren't that bad
18:37:09 <morganfainberg> bknudson, it's why we add the buffer migrations.
18:37:21 * morganfainberg has done it at least once
18:38:19 <morganfainberg> my concern is what adam raised... how bad will this break clients having multiple assignments with the same name/etc/etc except "inherited" being flagged
18:38:27 <henrynash> so that is teh current design (and is what is exposed via the API)…this patch is to fix a bug I created when I implemented this, in that, dur to the way I created the scehma, you can’t have an inherited and a non-inhertited assignment on teh sameobject
18:38:48 <bknudson> this is exposed in GET /v3/role_assignments or something?
18:38:57 <rodrigods> yes
18:39:00 <henrynash> so I need to understand what that cocerns is
18:39:04 <ayoung> henrynash, I'd need to see the origianl arguments, but as done right now, it won't work.  We break every API and UI that assumes a role is assigned once and only once
18:39:17 <bknudson> http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#list-effective-role-assignments
18:39:21 <henrynash> i just don’t undestad that stattement
18:39:35 <ayoung> instead, we need to quantify on the assignment the "inheritability " of it
18:40:00 <ayoung> henrynash, we break horizon if there are multiple roles on the same project
18:40:02 <henrynash> inherited roles are a bit like group roles….a user may end up with teh same “role” on the same object…..
18:40:02 <rodrigods> ayoung, but the role is assigned once and only once
18:40:04 <ayoung> er...
18:40:09 <ayoung> multiple gah
18:40:30 <henrynash> ayoung: through what API would we break horizon?
18:40:34 <ayoung> anyway, make it an enumerated field and we manage to solve the whole problem
18:40:48 <bknudson> you can get the effective role assignments... will that return both now?
18:40:49 <ayoung> instead of a boolean, make it a 3 value
18:40:57 <henrynash> ayoung: wht do that?
18:41:06 <samueldmq> we don't break horizon, etc .. I think the concern is the UX
18:41:11 <rodrigods> bknudson, effective doesn't return for the target itself if the inherited flag is active
18:41:23 <bknudson> I'd think changing the bool to enum would be a bigger API break.
18:41:25 <henrynash> ayoung: there is no proposal to chaneg the API, so why do we need to store more than two values?
18:41:28 <ayoung> effective role assignments for an inherited assignment would not give the parent....
18:41:31 <ayoung> you know what, this is dumb
18:41:36 <samueldmq> in general, it works as design, but the main concern is wheter to represent when a role asingment belongs to both parent + children in a single assingment
18:41:54 <ayoung> I don't like the "this role assignment is only for the children, not the node"
18:42:03 <ayoung> what use case is that actually serving?
18:42:04 <samueldmq> I think the naming 'inherited' may carry someone to think it's applied on both parent + childrne
18:42:11 <rodrigods> ayoung, this makes sense for the domain use case
18:42:16 <morganfainberg> ayoung, that seems like the core part of the bad design.
18:42:18 <ayoung> samueldmq, and it should be implemented that way...why was it not?
18:42:21 <henrynash> ayoung: I understand that, but that is not up for debate in K, fixing the current implementation is
18:42:38 <samueldmq> ayoung, this was a design decision you took
18:42:53 <ayoung> henrynash, of course it is up for debate.  I'd rather yank the whole feature than ship something broken
18:43:03 <henrynash> ayoung: it’s not broekn
18:43:06 <ayoung> and...all I am asking is "why?"
18:43:08 <rodrigods> ayoung, that breaks the API
18:43:11 <ayoung> henrynash, convince me
18:43:16 <ayoung> it sure sounds broken to me
18:43:16 <morganfainberg> we could move the needle either way: allow multiple assignments [one for <parent> and one that is <inherit>] - or we could allow inherit to apply to <local> as well
18:43:31 <morganfainberg> i think *either* would be fine.
18:43:39 <rodrigods> the second doesn't break the API?
18:43:46 <ayoung> yes it does
18:44:08 <morganfainberg> both break API
18:44:17 <samueldmq> the first one no, I think
18:44:22 <morganfainberg> it's a question which way do you break it
18:44:22 <ayoung> we have already confused the entire world multiple times with strange rules from Keystone.   Let us not do it again.
18:44:24 <rodrigods> ++
18:44:26 <henrynash> please explain how what we are proposing (In this patch) breaks anything!
18:44:28 <rodrigods> why the first one breaks?
18:44:44 <bknudson> I don't see what breaks.
18:44:44 <samueldmq> henrynash, ++
18:44:48 <samueldmq> I think we have 2 things here
18:44:56 <samueldmq> i) fix the documented behavior
18:45:05 <samueldmq> ii) design decision, what is better for UX
18:45:07 <morganfainberg> this also has been broken a loooooong time.
18:45:15 <morganfainberg> or "wierd" at least
18:45:25 <morganfainberg> wh-eird
18:45:31 <rodrigods> its definitely weird
18:45:33 <samueldmq> the weird we fix on ii) ^
18:45:37 <bknudson> something that failed before can be changed to work -- https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Considered_OK
18:45:39 <samueldmq> the wrong we fix on i) ^
18:45:44 <samueldmq> the patch we have for it
18:45:48 <henrynash> morgainfainberg: it’s not come up really before because it does represnet what people want to do in the domain-project situaation
18:46:08 <morganfainberg> bknudson, which is why i think we break the API but no in an unacceptable way regardless of the way we go
18:46:17 <morganfainberg> bknudson, making inherit apply to the local node is logical
18:46:26 <morganfainberg> *or* we allow multiple assignments
18:46:29 <bknudson> to the domain?
18:46:29 <henrynash> morgainfainberg: i.e. teh roles you appl y to projects (i.e. children of teh daomin) are usually not the same as you want to have active on the domain itself
18:46:30 <morganfainberg> either side could be considered a bug
18:46:34 <morganfainberg> bknudson, yeah
18:46:52 <bknudson> what does allowing multiple assignments break?
18:46:59 <henrynash> bknudson: ++
18:47:02 <rodrigods> bknudson, that's the question
18:47:08 <morganfainberg> bknudson, potentially lots of clients assuming 1 and only 1 instance of the role
18:47:13 <morganfainberg> in the assignment for things
18:47:21 <bknudson> where? what API?
18:47:23 <morganfainberg> bknudson, again, it's implied contract.
18:47:29 <morganfainberg> it's how it works
18:47:33 <morganfainberg> not how it is documented to work
18:47:40 <morganfainberg> anyway
18:47:45 <samueldmq> bknudson, it does not break anything, I think it's just the naming we have "inherited", which would cause one to think it's applied to both, when it's not
18:47:46 <henrynash> morgainfainberg: but that happens today with group roles and direct user roles.....
18:47:50 <morganfainberg> as long as we don't break people I'm fine.
18:47:55 <morganfainberg> either way
18:48:01 <rodrigods> henrynash, ++
18:48:10 <morganfainberg> though i think it's a silly silly thing to need to say "assign" no "also assign and inherit"
18:48:20 <morganfainberg> a very silly thing
18:48:30 <lhcheng> I don't see how it would break horizon, just probably a bad UX on the role assignment page.
18:48:42 <lhcheng> should be fine
18:48:42 <ayoung> this is, I think, making a bizare API as a work around for the "admin is GOD" problem
18:49:15 <ayoung> lhcheng, projects will show up that the user has no role on
18:49:20 <henrynash> ayoung: we aren’t changing the API
18:49:33 <henrynash> ayoung: huh?
18:49:37 <ayoung> leave it as is, then, and let this shake out in Liberty\
18:49:56 <samueldmq> leaving as it is is bad for hierarchical projects
18:49:58 <samueldmq> imo
18:50:02 <henrynash> ayoung: you need to come up with a thing that will break, I ain’t herad nothin yet
18:50:02 <rodrigods> exactly
18:50:14 <samueldmq> for domains that was ok, but for hmt it is just bad
18:50:15 <henrynash> (cue that song)
18:50:42 <lhcheng> ayoung: that part is all in Keystone, as long as the keystone policy allows it
18:51:07 <ayoung> yeah...I guess list projects for users is what Horizon does, and the parent proejct won't show up
18:51:21 <morganfainberg> i *really* *really* don't have a clue how the design to make inherit to not include the domain was made.
18:51:21 <lhcheng> ayoung: when the user scopes to the sub-project, the inherited role should still be in the auth token
18:51:27 <bknudson> this doesn't have anything to do with hierarchical projects?
18:51:34 <ayoung> its just if someone did list role assignements and tried to script it they would be getting false positives
18:51:41 <samueldmq> ayoung, no, not for inherited assignments, (and horizon does not assign inherited assignments yet)
18:51:41 <ayoung> its still shortsighted
18:52:11 <bknudson> I thought it was just domains.
18:52:17 <morganfainberg> bknudson, it does apply to HMT since inheritance works there as well [or will with reseller]
18:52:23 <samueldmq> bknudson, yes it does, having the same role on the parent + children makes sense (and didnt for domain + children)
18:52:49 <morganfainberg> samueldmq, i disagree with the assertion that domain + child project doesn't make sense.
18:52:58 <morganfainberg> but i guess i'm in the minority here.
18:53:30 <rodrigods> it will definitely won't when we have projects that are domains
18:53:36 <samueldmq> morganfainberg, well, I cant see a scenario it does ... I think we would have a role like 'project_admin' and then assign inheritance
18:53:40 <ayoung> its cuz our role names are too broad
18:53:51 <samueldmq> morganfainberg, but someone who really uses it may come with the real usecase
18:53:53 <ayoung> "admin is everything"
18:53:55 <morganfainberg> ayoung, i think this is something we need to address in liberty
18:54:02 <ayoung> same sack of concrete
18:54:07 <ayoung> morganfainberg, +++++++
18:54:11 <morganfainberg> not in kilo
18:54:12 <rodrigods> morganfainberg, , it must be addressed
18:54:28 <samueldmq> we just want to fix the implementation
18:54:31 <rodrigods> the single assignment type only works with separate admin roles
18:54:33 <samueldmq> if we go for changing the design
18:54:39 <morganfainberg> i think the conversation becomes even muddier with domain as a project
18:54:39 <samueldmq> this should come after (in L)
18:54:46 <morganfainberg> and we'll have the same issues/different bag
18:54:47 <lhcheng> ayoung: The part that could break is probably when assigning the project roles to user/group, have to provide a way for user to set if it is inherited/or not.
18:54:58 <lhcheng> samueldmq is right, it is not there yet.
18:55:12 <morganfainberg> is there a reason this *has* to be fixed *right now at the 11th hour before release*?
18:55:14 <samueldmq> morganfainberg, please lets fix the code against what is specified
18:55:17 <henrynash> morganainberg: I don’t see how fixing the implementation puts us in any worse situation for any deisgn re-work we may chose to do in Liberty
18:55:25 <samueldmq> morganfainberg, if we go for changign the api, we do that in L
18:55:34 <samueldmq> henrynash, ++
18:55:39 <morganfainberg> henrynash, because we're springing behavioral changes on users at the last minute
18:56:02 <samueldmq> fixing the implementation does not mean we wont revisit this and possibly change the design
18:56:16 <henrynash> morganfainberg: I just don;t see that…this is MEANT to work, and it errors when you try to execute the published API in an odd way
18:56:18 <morganfainberg> henrynash, and i don't mean deployers strictly i mean *all* users.
18:56:27 <henrynash> (I mean it errors in an odd way)
18:56:40 <morganfainberg> henrynash, meant to work and changing how it works right before the release is a cause for my hair to turn grey ;)
18:56:50 <morganfainberg> two different things
18:57:15 <morganfainberg> henrynash, my #1 concern in this case is changing a behavior last minute
18:57:38 <morganfainberg> and we all know how well we find out about bugs... 1yr down the line with angry users
18:57:39 <samueldmq> henrynash, this is even worst since we are silent for duplicated assignments
18:57:43 <samueldmq> #link https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L129-L131
18:58:23 <bknudson> that's bad.
18:58:31 <morganfainberg> bknudson, well not really.
18:58:32 <samueldmq> yeah we fail silently
18:58:48 <henrynash> samueldmq: oh I see, you call the API….it says OK, but it doesn’t apply the assignemnt you made!
18:58:49 <morganfainberg> bknudson, it's perfectly fine to give a 201 [i assume thats what we get] if you already have the assignment
18:58:58 <samueldmq> henrynash, yeah
18:59:00 <morganfainberg> henrynash, since the assignment already existed
18:59:04 <bknudson> but you don't have the assignment... it's a different assignment.
18:59:13 <rodrigods> bknudson, ++
18:59:19 <ayoung> https://github.com/openstack/keystone/blob/master/keystone/assignment/backends/sql.py#L61
18:59:27 <ayoung> yeah...this is messed up in a couple different ways
18:59:43 <morganfainberg> ok so the migration is *not* strictly the fix
18:59:46 <morganfainberg> can we step back
18:59:57 <morganfainberg> propose the fix in a backportable way to RC2
19:00:00 <morganfainberg> not jkust the migratin
19:00:03 <morganfainberg> migration
19:00:12 <morganfainberg> look at the other associated issues
19:00:24 <ayoung> For list_grant_role_id  we would need to do a hierarchical query
19:00:33 <morganfainberg> so, we have a lot of issues
19:00:43 <ayoung> we have a lot of stuff that, maybe it works, but doesn't look like it in first glance
19:00:48 <morganfainberg> we're out of time
19:00:52 <morganfainberg> off to -keystone
19:00:56 <henrynash> morganfainberg: not sure I understand the distinction of migration vs fix?
19:00:56 <morganfainberg> sorry
19:01:01 <morganfainberg> #endmeeting