18:00:12 <ayoung> #startmeeting keystone
18:00:13 <openstack> Meeting started Tue Dec 11 18:00:12 2012 UTC.  The chair is ayoung. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:17 <openstack> The meeting name has been set to 'keystone'
18:00:25 <gyee> o/
18:00:40 <henrynash> hi
18:00:50 <kwss> hello
18:00:59 <ayoung> dolphm is going to away for most, but should be joining us at the end
18:01:25 <ayoung> And I don't see heckj around
18:02:17 <ayoung> #link http://wiki.openstack.org/Meetings/KeystoneMeeting
18:02:35 <henrynash> ayoung: I added the item of a reference implementation for groups to the agenda
18:02:52 <ayoung> Although we are going to move the discussion of Module Refactoring to the end, to hopefully get dolph's input
18:02:59 <ayoung> henrynash, sounds goodf
18:03:43 <ayoung> We should also probably start doing a review of previous minutes in these, to make sure old "todo" items are covered.  But we had no #actions from last time
18:04:12 <dwchadwick> Did we cover all the items from last week?
18:04:31 <ayoung> dwchadwick, lets see...
18:04:49 <ayoung> #link http://eavesdrop.openstack.org/meetings/keystone/2012/keystone.2012-11-27-18.10.html
18:05:26 <ayoung> I'd have to dig out the revision history in the Wiki to see what the agenda was.
18:05:26 <dwchadwick> tunnel
18:06:09 <henrynash> dwchadwick: do you see the light at the end of the tunnel or is that a train going your way :-)
18:06:21 <ayoung> old agenda was
18:06:23 <ayoung> High priority bugs or immediate issues?
18:06:23 <ayoung> Open discussion
18:06:23 <ayoung> Groups vs. attribute mappings
18:06:23 <ayoung> Adding IDPs to service catalog
18:06:23 <ayoung> https://blueprints.launchpad.net/keystone/+spec/adding-idps-to-service-catalog
18:06:24 <ayoung> Delegation
18:06:26 <ayoung> http://wiki.openstack.org/keystone/Delegation
18:06:28 <ayoung> Status/Timeframe of Federation integration
18:06:30 <ayoung> http://wiki.openstack.org/Keystone/Federation/Blueprint
18:06:32 <ayoung> https://blueprints.launchpad.net/keystone/+spec/adding-idps-to-service-catalog
18:06:36 <ayoung> I think we covered all that.
18:06:44 <ayoung> OK. let start with
18:06:52 <ayoung> #topic High priority bugs or immediate issues
18:07:46 <ayoung> 2 new (untriaged) bugs, neither seem high priority:  One is a test bug the other is  https://bugs.launchpad.net/keystone/+bug/1087234
18:07:47 <uvirtbot> Launchpad bug 1087234 in keystone "It should be possible to delete a tenant by its name" [Undecided,New]
18:07:50 <ayoung> RFE
18:08:47 <ayoung> Looking at the high priority bugs:
18:09:05 <ayoung> 0 critical
18:09:15 <ayoung> #link https://bugs.launchpad.net/keystone/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed
18:09:31 <ayoung> 15 High
18:09:34 <ayoung> https://bugs.launchpad.net/keystone/+bugs?search=Search&field.importance=High&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed
18:10:32 <henrynash> ayoung: targets for bug squashing on Thursday?
18:10:41 <ayoung> henrynash, good question
18:11:16 <henrynash> I'be got some IBMers coming up to speed on keystone…so could direct them at whatever we select
18:11:25 <ayoung> henrynash, none of the high look like something we can just "knock out."
18:11:59 <ayoung> henrynash, potentially this one https://bugs.launchpad.net/keystone/+bug/1040696
18:12:00 <uvirtbot> Launchpad bug 1040696 in keystone "invalid EC2 signature authentication for requests without a port" [High,Triaged]
18:12:40 <ayoung> OK,  let me give a quick status on the refactoring and then we can table the rest of the discussion until dolph is present
18:12:47 <ayoung> #topic Module Refactoring
18:12:48 <henrynash> and https://bugs.launchpad.net/keystone/+bug/1061738
18:12:49 <uvirtbot> Launchpad bug 1061738 in keystone "create_service() returns 500 Internal Server Error when bad keyword arg (XML only)" [High,Triaged]
18:13:08 <ayoung> henrynash, yeah, that would be a good one to look at, too
18:13:17 <ayoung> Ok,  the service.py file was too fat
18:13:34 <henrynash> :-)
18:13:51 <ayoung> and, it was not quite possible to move the TokenController into the token module package  (keysteon/token) due to a circular dependency
18:14:01 <gyee> ayoung, looks like you are doing massive refactoring, should I start on the token work now or wait for you?
18:14:03 <ayoung> so I've been shuffling files around
18:14:16 <gyee> otherwise, one of us well be busy rebasing
18:14:21 <gyee> will
18:14:24 <ayoung> gyee, I think we all need to focus on understanding this refactoring before doing any more work on modules
18:14:33 <gyee> k
18:14:40 <ayoung> review is this one
18:14:51 <ayoung> #link https://review.openstack.org/#/c/17782/
18:15:15 <gyee> I see a cross from dolph
18:15:17 <henrynash> ayoung: agreed (although I have just about completed the changes for a reference implementation of groups on the server side - so refactoring, I gotta do!
18:15:30 <ayoung> gyee, right, which is why we need him here to discuss
18:16:07 <ayoung> henrynash, if you push your changes as a WIP review, I can give you guidance how to reshuffle based on the refactoring
18:16:25 <henrynash> ayoung: great, thx
18:16:48 <ayoung> OK,  keeping that in mind, let's table the rest of the discussion on the refactoring, and move on.
18:16:54 <henrynash> ayoung: you mean a git review -D ?
18:17:10 <ayoung> henrynash, yes
18:17:15 <ayoung> get review -w
18:17:30 <henrynash> ayoung: ok, thx
18:17:36 <ayoung> it will show up as a WIP.  We'll be able to see it, but it won't be in danger of getting merged
18:18:10 <ayoung> #topic Groups/Attributes
18:18:15 <henrynash> (assuming we want the defence design in…but that's another topic)
18:18:25 <henrynash> ahh, I mean, this topic :-)
18:18:40 <ayoung> #action henrynash submites WIP review of reference impl thus far
18:18:59 <ayoung> henrynash, the floor is yours.  What are the issues?
18:19:43 <henrynash> so the fundamental question is whether it is in our best interest to start with a defence design based on current RBAC capabilities
18:19:57 <henrynash> (sorry, I meant a "reference" design)
18:20:30 <henrynash> …and then start plugging in the attribute capabilities and cut out the bits of the reference design no lover needed
18:20:40 <henrynash> (longer)
18:20:54 <ayoung> henrynash, your typos are getting freudian
18:21:04 <henrynash> I aim to amuse :-)
18:21:52 <henrynash> current state is that the keystone client reference design is already up for review at https://review.openstack.org/#/c/17693/
18:22:06 <ayoung> #link  https://review.openstack.org/#/c/17693/
18:22:20 <henrynash> …and the server side will be ready for review (WIP as necessary) later this week
18:22:46 <dwchad2> Henry, if you have spare development cycles, why not work with Kristy on attribute mapping
18:22:49 <ayoung> henrynash, I think we need to see that.
18:23:24 <gyee> ayoung, should we wait for henrynash's keystone impl before review the client changes?
18:23:26 <henrynash> dwchad2: so have made comments to the attribute mapping api proposals
18:23:38 <ayoung> henrynash, link?
18:24:09 <dwchad2> henry: been in london at a meeting all day so not had chance to see them yet
18:24:11 <kwss> henrynash: I got an email but can't see the comments in google docs
18:24:51 <henrynash> kwss: sometimes they are in the comments button at the top - and could you post the link to your doc in this IRC?
18:24:56 <dwchad2> what is the advantage of putting in groups now, if they are going to modified in a few weeks time?
18:25:31 <ayoung> #link https://docs.google.com/a/kent.ac.uk/document/d/1cObK3P_ic9XSTwJRFsmimG94LDnFbsPbvx_H1aM1FPI/edit#
18:25:43 <ayoung> Is that still the current doc?
18:26:15 <kwss> yes
18:26:20 <kwss> ayoung: yes
18:26:28 <henrynash> dwchad2: I think we have to consider any attribute based implementation experimental until we get through all the details (which I have no doubt we will in the end)….but the RBAC solution is pretty simple, straightforward and we know will work
18:27:18 <henrynash> kwss: so on my copy, my comments come up if you click the comments box at the top….
18:27:27 <dwchad2> but your use of attribute mapping wont be experimental since it will map groups into roles and tenants. So there are no "attributes" involved (except that they are all attributes!)
18:28:15 <kwss> henrynash: I see them now, I'll respond after the meeting :)
18:28:25 <henrynash> kwss: no problem, thx
18:28:35 <dwchad2> attribute mapping is another way of implementing groups that can be made invisible to end users, and it a step on the way to federation, whereas groups on its own is not
18:29:05 <ayoung> henrynash, I am going to kind of leave it up to you for now.  If you think you can get the groups impl working on top of attributes, and do so in the Grizzly time frame, I think that would be the best approach, but I can see that might be too tight a dependency
18:29:45 <henrynash> dwchad2: agreed….and hence the proposal of the reference design that we then start using the attribute mapper to store the relationships...
18:29:50 <ayoung> I'd almost like to do attributes like we did PKI:  get it in and usable in Grizzly, and then, in H, make it the default for all the things that are going to use them
18:30:49 <henrynash> ayoung: I'm happy to put the work in on top of the basic reference implementation so that we start exploring how we sue attributes for this
18:30:51 <ayoung> I think once we have Attributes etc, retrofitting APIs to use them will be fairly straightforward, so we should hold things up waiting for them for fear of future work.
18:31:03 <henrynash> ayoung: agreed
18:31:26 <ayoung> dwchad2, kwss, does that pass the sanity test?
18:32:30 <dwchad2> ayoung: did you mean not
18:33:09 <ayoung> dwchad2, yes "we should *not* hold things up..."
18:33:30 <kwss> makes sense to me
18:34:02 <ayoung> #agreed  Groups goes forward ontop of RBAC, gets retrofitted in H release
18:34:16 <dwchad2> If Henry has spare dev cycles I would rather he works with Kristy on attributes now and they will have it finished in half the time
18:34:44 <ayoung> dwchad2, yes, but then we still need to do the Groups implementation on top of it
18:34:57 <ayoung> Which will likely push it out of the Griz release
18:35:05 <dwchad2> Since there are many many things to do in Keystone, creating extra work is a big issue to me
18:35:10 <ayoung> understood
18:35:38 <ayoung> but we need to balance the demand from the other projects with the need to set things up for the long term....hard line to walk
18:36:07 <dwchad2> The groups work is the easiest bit once you have attribute mapping since all Henry needs to do is add roles to the backend and pull them out. No other API changes are needed
18:36:31 <henrynash> dwchad2: I'll happily work with Kristy to add support for attributes once we have the reference design - I really think this is at the safer route
18:36:43 <dwchad2> With Henry's current plan there is a lot of changes needed to  the APIs
18:36:49 <ayoung> dwchad2  I am not sure I agree.  I think we are going to need a deliberate group api to give off to the other projects.
18:37:17 <ayoung> dwchad2, that is fine, lets get them in the review.  I think the focus should be nailing down the APIs for groups
18:37:26 <dwchad2> The group API you need is to add groups to users and retrieve groups from users
18:37:55 <dwchad2> then the AM maps the groups into roles and tenants and domains and whatever else you need
18:38:01 <gyee> also, assigning roles to them
18:38:17 <ayoung> gyee, dwchad2 this is where things get gray
18:38:25 <ayoung> we can treat everything as an attribute internally
18:38:35 <dwchad2> gyee: no, since you already have the apis for adding roles to users
18:38:40 <ayoung> but we need to export APIs to the end users that speak their language.
18:39:06 <ayoung> dwchad2, but we don't have the API for adding roles to groups
18:39:13 <gyee> whole point of doing groups is we don't have to directly assigning roles to users
18:39:28 <dwchad2> You dont add roles to groups. You set up attribute mappings for this
18:39:29 <ayoung> I understand that we could do that with the mapping API, but I think it will be too low level
18:40:05 <gyee> how does attribute map API works?
18:40:10 <ayoung> dwchad2, gyee hold on
18:40:20 <ayoung> lets not get into a design discussion right now
18:40:24 <ayoung> here is the chase
18:40:47 <ayoung> we need to expose an API that people will understand.  Educating them on ABAC and Attribute mapping will take time
18:40:51 <dwchad2> we already have a published design, so we should discuss this after the meeting
18:41:01 <ayoung> dwchad2, +1
18:41:21 <dwchad2> ayoung: +1
18:41:59 <ayoung> dwchad2, so I think we have an Education task as far as ABAC etc.  First thing is to get ABAC into the code base.  We can then show how we use it to do things that were more "hard coded" in the past. and then replace the hard coded implementations with ABAC
18:42:41 <dwchad2> clearly having working code you can demonstrate is far better to end users than a blueprint :-=)
18:42:55 <dwchad2> Just like it was with federation
18:43:02 <ayoung> However, that does not mean we hold off on new features until ABAC is in.  While I know you have a good grasp on the implementation details, I still think it is going to take longer than you think to get to the point where we can depend on it
18:43:20 <dwchad2> actually we are not adding ABAC initially
18:43:27 <dwchad2> we are only adding AM
18:43:39 <dwchad2> the authz is still RBAC using existing roles
18:43:40 <ayoung> dwchad2, I am lumping attribute mapping into ABAC.  I realize I am being imprecise.
18:44:19 <dwchad2> yes, its a multi step process. And AM is one way of implementing groups and RBAC which is an intercept strategy for ABAC and federation
18:44:33 <henrynash> dwchad2: but the underpinning is the same entities (sets, mappings etc.) and the api to go with it - it will be important for us to really get that right…since once it is in there, we will depend on it for a longtime
18:44:39 <dwchad2> So you dont waste any time and coding
18:45:10 <ayoung> OK,  We need to make sure we talk about the Keyring thing.  I'm going to move us along....
18:45:11 <dwchad2> the api we have designed is fully generic and extensible
18:45:39 <ayoung> #topic Keyring
18:45:40 <dwchad2> so adding domains becomes very easy
18:45:48 <henrynash> ayoung: I need to ask if the action you stated a while back still stands on this
18:45:54 <henrynash> (to close it out)
18:46:13 <ayoung> henrynash, well, understand I am not PTL, so it is just my call, not an official project call
18:46:36 <henrynash> ayoung: OK, understood
18:47:21 <ayoung> I'd take it as a suggestion for now, and drive forward with the groups work as is, especially since you already have the code nearly done.  We'll take it up again post code review?
18:47:40 <henrynash> ayoung: ok, agreed
18:47:44 <ayoung> #action revisit Groups once Attribute Mapping and Groups reviews are both posted
18:47:52 <ayoung> OK,  Keysring
18:48:04 <gyee> keyring
18:48:09 <ayoung> gyee, here is my understanding
18:48:30 <ayoung> we want keyring as a long term tool, but we need to be sneaky about it.  And we got caught
18:49:08 <dwchad2> what is keyring. Do you have a URL
18:49:21 <ayoung> There are many issues around credentials caching, probably most significantly when the user is an automated daemon
18:49:38 <gyee> ayoung, disabling keyring by default means on one will use it, ever :)
18:49:41 <ayoung> gyee, can you summarize Keysring support
18:49:48 <ayoung> gyee, understood
18:49:58 <ayoung> but we need to do that initially
18:50:01 <ayoung> like PKI tokens
18:50:14 <ayoung> get it in, but disabled
18:50:14 <gyee> we added keyring support in keystoneclient so we can cache tokens in keyring
18:50:41 <gyee> advantage #1 no need to keep requesting tokens
18:50:41 <ayoung> then work out the issues with explicitly  enabling it in Devstack.
18:50:50 <ayoung> gyee, to be specific
18:50:56 <gyee> #2 no need to have passwords in env var
18:51:19 <ayoung> if we cache the unscoped tokens, we only need to request a new one when they are about to time out, and we can continue to use them to request scoped tokens
18:51:31 <gyee> yes
18:51:33 <ayoung> gyee, so there is the rub...#2
18:52:13 <ayoung> for an automated daemon, we need to be able to deal with initializing keyring without user interaction, much like a kerberos Keytab
18:52:28 <gyee> problem is there are two usage of python-keystoneclient, interactively and non-interactive
18:52:59 <ayoung> gyee, right, so we need to keep it disabled by default until we clear up how to solve the non-interactive use cases
18:53:40 <gyee> ayoung, I'll need to do some code diving
18:53:47 <gyee> I mean looking at the keyring impl
18:53:56 <ayoung> dwchad2, I think I have a link to the upstream package we are pulling in for Keyring, but basically it is a python front end to things like nss databases, openssh keys, etc.  A (hopefully secure)  credential cache
18:55:56 <ayoung> #link http://bitbucket.org/kang/python-keyring-lib
18:55:57 <gyee> if your login password is the same as your keyring password, ubuntu won't prompt for keyring password
18:56:01 <ayoung> That is from
18:56:08 <ayoung> /usr/lib/python2.7/site-packages/keyring-0.9.2-py2.7.egg-info/PKG-INFO
18:57:24 <ayoung> gyee, there is also the question about whether tokens should get shared between applications that are all using keystone client.  My thought is "of course" but I suspect some people will object.  Also,  we need to figure out what to do if keyring is installed on a machine that is running horizon
18:57:40 <ayoung> tokens should not get cached the same way from HTTPD....
18:57:50 <gyee> that's what keyring is for
18:58:27 <gyee> think of keyring as your browser cookie jar
18:58:39 <ayoung> gyee, can I ask you to write up what the overall strategy is for implementing keyring, and covere those 3 uses:  automates, HTTPD, CLI?
18:59:04 <ayoung> I think we need to be able to point people at that doc when we try to educate them about the usage.
18:59:23 <gyee> sure
19:00:45 <ayoung> #action gyee to write up  strategy is for implementing keyring,  covering (at least) 3 uses:  automated , HTTPD, CLI
19:01:08 <ayoung> OK, that is 2PM.  No dolphm so we are going to have to table the discussion on the refactoring.
19:01:16 <ayoung> Any last points before we get kicked out?
19:01:33 <ayoung> #topic Test Coverage
19:01:44 <ayoung> #link http://admiyo.fedorapeople.org/openstack/covhtml/
19:02:21 <ayoung> I'll update that post refactoring, but please take a look at the pieces you are working on, and try and expand the unit test coverage.  That is all.
19:02:40 <ayoung> #endmeeting