18:02:26 <morganfainberg> #startmeeting Keystone
18:02:27 <openstack> Meeting started Tue Oct  7 18:02:26 2014 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:30 <openstack> The meeting name has been set to 'keystone'
18:02:47 <morganfainberg> Lets get started then
18:02:51 <morganfainberg> #topic IRC Meeting Time
18:03:10 <morganfainberg> Is this still a good time for the meeting? I'm happy but since it's a new cycle, just checking before we continue with it vs. trying to reschedule
18:03:28 <topol> time works for me
18:03:28 <stevemar> +1 for current meeting time
18:03:33 <ayoung> This has been a good time thus far
18:03:37 <nkinder> yeah, good for me too
18:03:40 <lbragstad> +1
18:03:43 <raildo> time works for me too
18:03:44 <rharwood> this is good
18:03:47 <dstanek> ++
18:03:50 <rodrigods> ++
18:03:58 <morganfainberg> cool. lets stick with it then.
18:04:09 <morganfainberg> #topic Marking Specs as Implemented [Keystoneclient, Keystonemiddleware, etc]
18:04:10 <dolphm> (belated o/)
18:04:24 <ayoung> Ohh, I have one that is in a -1 state that is implemented
18:04:27 <morganfainberg> so, we should mark completed specs as .. completed.
18:04:47 <dolphm> ayoung: -1 state?
18:05:07 <ayoung> https://review.openstack.org/#/c/106438/
18:05:13 <morganfainberg> what makes the most sense for that? change the title? change the spec? move it? (this impacts keystoneclient/middleware more than Keystone server)
18:05:18 <stevemar> morganfainberg, separate list of completed vs proposed?
18:05:19 <ayoung> Fetch policy based on endpoint
18:06:02 <ayoung> dolphm, yeah, henrynash got ahead of me and implemented it.
18:06:14 <morganfainberg> stevemar, basically look at the repo now... how do you know what's been implemented / closed without also looking at LP?
18:06:19 <henrynash> ayoung: :-)
18:06:34 <ayoung> it was just posted as a place holder
18:06:36 <stevemar> morganfainberg, i know what you mean, and i don't know given it's current state
18:07:18 <morganfainberg> we could just move them to "implemented" directory (probably easiest)
18:07:19 <stevemar> morganfainberg, under KSC have a sub section for completed vs and another for proposed/approved
18:07:25 <ayoung> henrynash, care to close the loop on that one?
18:07:37 <dolphm> ayoung: that looks like it can be abandoned, no?
18:07:42 <ayoung> dolphm, sure
18:07:43 <morganfainberg> dolphm, ++
18:07:56 <henrynash> ayoung: go ahead and kill it...
18:08:04 <ayoung> dolphm, is there any benfit to approving a cleaned up version ex-post-facto?
18:08:13 <ayoung> To document what we were doing?
18:08:28 <ayoung> henrynash, did you work with a different review for the spec?
18:08:36 <morganfainberg> stevemar, mind taking a look at the specs repo and what would look cleanest to get it a bit more clear on what has been finished?
18:08:57 <stevemar> morganfainberg, sure
18:09:02 <morganfainberg> stevemar, awesome, thanks.
18:09:16 <morganfainberg> #action stevemar to look into indicating specs that have been completed in the repo
18:09:45 <morganfainberg> anyone have strong feelings about it before we move on (how we indicate a spec is complete)?
18:10:22 <ayoung> OK,  abandoning mine.
18:10:43 <henrynash> ayoung: sso I thought I had a different spec…hunting for it now
18:10:44 <dolphm> morganfainberg: did we have a consensus about "abandoned" specs? / ones that won't be completed
18:10:50 <ayoung> http://git.openstack.org/cgit/openstack/keystone-specs/tree/specs/juno/endpoint-policy.rst
18:10:53 <ayoung> henrynash, ^^
18:10:57 <morganfainberg> dolphm, no don't think so
18:11:16 <morganfainberg> #topic Abanadoned Specs (what do we do with them)
18:11:17 <dolphm> morganfainberg: is nova's policy still to leave them in the old release's dir?
18:11:28 <lbragstad> weren't those going to be bumped to the next release?
18:11:30 <morganfainberg> not sure.
18:11:34 <dolphm> "approved but unworked specs"
18:11:35 <ayoung> how about a "a parking lot" subdir
18:11:38 <henrynash> ayoung: ah, yep
18:12:11 <dolphm> lbragstad: i think that's the direction stevemar was going, but that directly conflicts with nova's philosophy, and i feel like we need a middleground (like ayoung's parking lot for homeless specs)
18:12:13 <gyee> any doc generated from the spec repo?
18:12:25 <dolphm> * nova's philosophy the last time i checked in
18:12:35 <dolphm> gyee: yes
18:12:40 <lbragstad> the parking lot idea is cool, give new contributes a place to look for work too?
18:12:46 <lbragstad> contributors*
18:12:47 <stevemar> dolphm, bump is author says it's cool, parking lot otherwise
18:12:54 <stevemar> i'm more than happy with that
18:12:57 <lbragstad> or just contributors in general
18:13:00 <dolphm> gyee: http://specs.openstack.org/
18:13:03 <ayoung> ++
18:13:07 <morganfainberg> yeah i'd be happy with a "parking" section
18:13:17 <topol> sounds good
18:13:33 <ayoung> sounds like consensus.  Should we do a formal vote?
18:13:33 <rodrigods> yeah, this sounds nice
18:13:42 <morganfainberg> ayoung, eh. sure?
18:13:45 <ayoung> heh
18:13:48 <ayoung> lets post it for review
18:14:18 <morganfainberg> ah, good idea, post it in the keystone-specs repo as part of the readme or something
18:14:22 <gyee> dolphm, cool
18:14:43 <dolphm> can we bikeshed on the name of the parking lot directory?
18:14:53 <morganfainberg> dolphm, only if it can be blue
18:14:58 <morganfainberg> dolphm, i mean orange
18:15:25 <ayoung> Lets call it  "the bike shed"
18:15:35 <morganfainberg> ayoung, you mind posting the change for that to the -specs repo?
18:15:49 <ayoung> #action ayoung to post change for parking lot to spec repo
18:15:54 <morganfainberg> ayoung, thanks!
18:16:05 <morganfainberg> ok, on a related topic
18:16:11 <morganfainberg> #topic Pulling Partially Implemented Specs to next release
18:16:27 <morganfainberg> for those that are partially implemented (aka non-persistent tokens) how should those be handled?
18:16:39 <morganfainberg> move the spec? re-propose with an update showing what was implemented?
18:16:56 <stevemar> oh i like re-propose
18:17:01 <lbragstad> it would be nice from a documentation perspective to know what about a specific spec went in per release.
18:18:48 <dolphm> morganfainberg: we just retarget the bp from one release series to another, i feel like the same can apply to the spec? or, what would you change in the spec otherwise? work items?
18:19:15 <morganfainberg> dolphm, i was thinking perhaps just copy the spec to the new target and indicate what was implemented last cycle.
18:19:45 <morganfainberg> dolphm, so spec stays the same, with just a little more info, but ends up in both relese directories to show it was implemented across both releases?
18:20:11 <stevemar> morganfainberg, yes, and include a link to N-1 release spec in the N release spec
18:20:13 <morganfainberg> dolphm, i'd also be ok with just moving the specs.
18:20:18 <ayoung> #link https://review.openstack.org/126647
18:22:46 <dolphm> ayoung: fixed a couple typos ^
18:23:08 <lbragstad> ayoung: comments on patchset on
18:23:09 <lbragstad> one*
18:24:06 <morganfainberg> so i'll try and put together something that links to the juno spec for non-persistent tokens and we can iterate on how that looks for any other partial specs going forward + documenting.
18:24:30 <morganfainberg> #action morganfainberg propose example "pull partial implemented spec forward to next release"
18:25:47 <morganfainberg> #topic defcore (keystone specific) requirements
18:25:52 <morganfainberg> hogepodge, o/
18:26:09 <hogepodge> Hi, some of you may know me from Puppet and the puppet-openstack community.
18:26:30 <hogepodge> I just joined the Foundation, and will be working on Interop. That's going to include working on whatever DefCore becomes.
18:26:44 <dolphm> hogepodge: (congrats!)
18:27:12 <hogepodge> I'd like to get integrated in the Keystone project more from a testing perspective, to try and work out what the core requirements for an OpenStack installation would be with respect to Keystone
18:27:31 <hogepodge> #link https://etherpad.openstack.org/p/keystone-defcore
18:28:04 <hogepodge> So I'll be around, probably asking questions, looking for feedback, and just generally trying to be as helpful as possible.
18:28:14 <ayoung> hogepodge, great, I have some reviews for you
18:28:35 <hogepodge> ayoung \o/
18:31:02 <morganfainberg> #topic Kilo Summit Sessions Discussion (continued)
18:31:05 <morganfainberg> #link https://etherpad.openstack.org/p/kilo-keystone-summit-topics
18:31:20 <morganfainberg> so i've added some tenative sessions to the top of the etherpad
18:31:31 <ayoung> we have a tenative schedule
18:31:39 <morganfainberg> ayoung, so we do
18:31:54 <ayoung> #link http://kilodesignsummit.sched.org/grid/
18:32:19 <ayoung> #link http://kilodesignsummit.sched.org/type/keystone
18:32:44 <morganfainberg> it's getting to the time where we'll be solidifying the sessions, please look over the discussion and let definitely let me know if there are concerns / conflicts / etc on when some of the sessions should/shouldn't be.
18:33:54 <morganfainberg> it looks like we'll be having (based on the link ayoung posted) our working time(s) wed, thurs, and friday
18:34:20 <ayoung> We should make a deliberate cross project meeting for Horizon to Keystone integration
18:34:31 <nkinder> ayoung++
18:34:32 <raildo> ayoung, ++
18:34:34 <nkinder> that's a big one
18:34:36 <ayoung> so many of our issues are driven by the need to support horizon
18:34:43 <morganfainberg> david-lyle, ^
18:34:45 <ayoung> david-lyle, ^^
18:34:49 <ayoung> heh
18:35:04 <david-lyle> we aim to cause problems
18:35:05 <henrynash> morganfainberg: so one thing I think we really want is enterprise user input into what we support with Keystone…which might be spread over the seesion, or odo we have a specific session as part of the UserOps part of the conference (if that exists this time around)
18:35:22 <dolphm> ayoung: the cross project track is intended for topics that span *all* projects, not just a pairing
18:35:29 <ayoung> david-lyle, and we make it easy for you to do so
18:35:39 <dolphm> ayoung: for a pairing, one project or another needs to dedicate it's own slot
18:35:42 <ayoung> dolphm, in a way it will,
18:35:47 <morganfainberg> dolphm, right but it wouldn't be inappropriate to consume either a horizon session or keystone session
18:35:54 <morganfainberg> dolphm, ++
18:36:13 <ayoung> Horizon really needs to depend on the service catalog abstraction to talk to all of the endpoints
18:36:31 <raildo> dolphm, hierarchical projects affects Keystone, Horizon and Nova, so this is a cross-projects session or a Keystone session?
18:36:54 <morganfainberg> henrynash, that might be best to dedicate to the pods / meetup day
18:36:55 <david-lyle> we're going to do our formalized session planning next week, but several keystone related topics are in the list
18:37:00 <dolphm> raildo: we did hierarchical multitenancy as a cross project session AND a keystone session in atlanta
18:37:10 <dolphm> raildo: not sure what's more appropriate this time around
18:37:13 <ayoung> we need to make sure that the meeting is focused on how Horizon consumes Keystone data in talking to all of the projects.  Hierarchical, multi-endpoints-per-service, and so on
18:37:17 <raildo> dolphm, ok
18:37:26 <morganfainberg> henrynash, instead of consuming a session slot for it.
18:37:47 <dolphm> david-lyle: when is the horizon meeting we should all attend? :)
18:38:03 <morganfainberg> henrynash, since I don't think we'll end up having a clear/consice target.
18:38:15 <morganfainberg> henrynash, for a 40min session
18:38:23 <morganfainberg> henrynash, if that makes sense
18:38:28 <henrynash> morganfainberg: what was the “user Ops” set of sessions call last time…
18:38:37 <topol> cool, we can all attend the horsizon session. love the crossover
18:38:37 <david-lyle> I'll let you know once I have a schedule, I'll try to make sure that horizon session doesn't overlap with a keystone one
18:38:42 <henrynash> morgainfaiberg: how quickly the brain forgets...
18:39:28 <henrynash> morganfainberg: there were a bunch of sessions for users to give their input on a variety of things…I was kind of angling for a keystone session as part of that, rather than one of our own
18:39:28 <morganfainberg> henrynash, well there were two things that happened, there was the Ops track which was more "ops specific" and we had (similar to what i'm planning this time) an open DevOps discussion, where keystone devs are available to discuss any devops topic
18:39:32 * david-lyle has to look back at the schdedule email
18:40:32 <morganfainberg> henrynash, yah, Keystone DevOps - absolutely planning that again. just run it like a panel, we )keystone devs) are available as a panel to answer/discuss anything operators/deployers want to ask.
18:40:32 <dolphm> david-lyle: oh, i meant IRC meeting
18:40:40 <henrynash> morganfaiberg: ah, Ok….just want to make sure that by tagging it “DevOps” we don’t imply this is specifically about that part of operations….(unless thats what we want!)
18:40:45 <dolphm> david-lyle: or whenever you're going to hash out the horizon summit schedule?
18:40:56 <morganfainberg> henrynash, i'll reword it before we make it on the official schedule
18:41:06 <morganfainberg> at ATL it was called "devops"
18:41:08 <henrynash> morganfainberg: ++
18:41:26 <dolphm> morganfainberg: +1 for panel, but follow up with tom fifield to find out what format worked best (as every service seemed to run that session differently)
18:41:35 <dolphm> and he attended them all
18:41:48 <morganfainberg> dolphm, i *heard* everyone liked ours. but will do
18:41:54 <david-lyle> dolphm, ah, just came online, think I missed some context
18:42:01 <dolphm> morganfainberg: he told me ours was one of the most "productive"
18:42:06 <morganfainberg> dolphm, right.
18:42:14 <morganfainberg> dolphm, i'll check with him as well.
18:43:32 <morganfainberg> The tentative list will be: Authorization topic covering tokens (and how we're going to handle that), non-token alternatives, etc
18:43:37 <morganfainberg> keystoneclient
18:43:48 <morganfainberg> object lifecycle (fix Dep injection)
18:43:56 <morganfainberg> and the Operator session
18:44:14 <morganfainberg> the other three are wide open, obviously that list is in flux and could change / open to being changed
18:46:32 <gyee> morganfainberg, role management
18:46:43 <gyee> time to solve the global adminness issue
18:47:02 <ayoung> gyee, hierarchical roles
18:47:11 <nkinder> gyee: you mean defining roles at a different level (like within a domain?)
18:47:11 <morganfainberg> gyee, sure, lets get some information on the etherpad about that. and we can consider it for a session
18:47:19 <gyee> nkinder, yes
18:47:32 <gyee> ayoung, ++
18:48:59 <gyee> ninkder, is there a session on security? right now the credential blob in Keystone are not encrypted
18:49:07 <raildo> ayoung, this? https://review.openstack.org/#/c/117787/
18:49:33 <ayoung> raildo, nope
18:49:39 <ayoung> raildo, this:
18:49:51 <ayoung> https://review.openstack.org/#/c/125704/
18:50:00 <ayoung> but not token enforces...needs to be in policy
18:50:06 <raildo> ayoung, ah, ok :)
18:50:51 <nkinder> gyee: there's no central "security" session, though the security group has proposed a cross-project session
18:51:01 <gyee> also, role to capability lookup, I am sure the Horizon folks will appreciate that :)
18:51:06 <ayoung> nkinder, ah...we need to solve the quota problem:
18:51:11 <nkinder> gyee: "security" is too much of a catch-all
18:51:45 <ayoung> nkinder, too much for this forum though
18:52:08 <gyee> take trust for example, when I delegate a role, I have no clue what exact capabilities I am delegating
18:52:20 <gyee> other just the other guy need it to get somethin done
18:52:26 <ayoung> gyee, hence capabilities
18:52:28 <ayoung> er
18:52:30 <ayoung> constraints
18:52:44 <ayoung> https://review.openstack.org/#/c/123726/
18:53:07 <ayoung> gyee, that is why we don't want to just depend on RBAC for trusts
18:53:23 <ayoung> RBAC is course grained, but we want fine grained delegation
18:53:36 <gyee> ayoung, ++ for fine grained
18:53:51 <ayoung> thought you would like that
18:55:19 <morganfainberg> 5min
18:55:50 <morganfainberg> Anything else before we finish up?
18:56:12 <morganfainberg> #topic Keystone Juno RC2
18:56:15 <morganfainberg> Soon.
18:56:29 <morganfainberg> if you find any bugs get them reported now.
18:56:45 <morganfainberg> and on that note.
18:56:47 <morganfainberg> #endmeeting