18:06:48 <ayoung> #startmeeting Keystone
18:06:49 <openstack> Meeting started Tue Jun 25 18:06:48 2013 UTC.  The chair is ayoung. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:06:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:06:52 <openstack> The meeting name has been set to 'keystone'
18:06:54 <gyee> yah ayoung!
18:07:17 <topol> gyee was sweating a potential battlefield promotion if you didnt show
18:07:43 <ayoung> Attending I see gyee topol lbragstad [1]fabio bknudson stevebaker
18:07:48 <ayoung> argh
18:07:50 <ayoung> stevemar,
18:07:55 <stevemar> ;)
18:08:00 <ayoung> dolphm is PTO
18:08:11 <bknudson> he earned it.
18:08:19 <topol> yep
18:08:24 <ayoung> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting
18:08:35 <bknudson> the rest of us have to step up and do code reviews.
18:08:37 <ayoung> #topic Havana milestone 2
18:08:48 <ayoung> What is burning for H2?
18:08:59 <ayoung> We have 3 weeks, and I am PTO next week.
18:09:00 <gyee> pluggable token provider?
18:09:03 <bknudson> probably henrynash
18:09:06 <bknudson> 's blueprints
18:09:10 <bknudson> and pluggable token provider
18:09:18 <bknudson> does pluggable token provider affect the api?
18:09:24 <gyee> bknudson, no
18:09:35 <ayoung> #link https://launchpad.net/keystone/+milestone/havana-2
18:09:58 <bknudson> service catalog affects the api
18:10:05 <gyee> ayoung, opt-out service catalog is high priority
18:10:08 <ayoung> Split Identity should be targetted there as well
18:10:11 <gyee> as it is impacting PKI token size
18:10:14 <ayoung> gyee, who is working on that?
18:10:20 <gyee> ayoung, fabio
18:10:26 <bknudson> There's a review up for it already.
18:10:32 <ayoung> [1]fabio, can you et that for H2?
18:10:36 <[1]fabio> yes
18:10:41 <ayoung> Ah,. OK. lets target H2 that
18:10:41 <bknudson> but it looked like the code was changing before the api spec.
18:10:44 <ayoung> link?
18:11:00 <gyee> #link https://review.openstack.org/#/c/33188/
18:11:14 <[1]fabio> I will make the API changes by EOW
18:11:21 <ayoung> [1]fabio, Get a blueprint link in there, and we cabn link the BP to the H2 release.
18:11:42 <gyee> [1]fabio, what up with the [1]?
18:11:53 <bknudson> to distinguish him from the other fabio
18:11:57 <[1]fabio> Don't know, stupid IRC client, I guess
18:12:00 <topol> the one and only fabio
18:12:05 <gyee> my keyboard is kindda [1] unfriendly
18:12:06 <bknudson> I can't believe it's not fabio
18:12:27 <topol> we did that joke last time
18:12:32 <gyee> [1] looks like a big f u sign
18:12:34 <gyee> sight
18:13:08 <gyee> just kidding
18:13:15 <topol> fabio I just edited my name. you should be able to as well
18:13:27 <bknudson> [1]fabio: looking forward to the api spec change.
18:13:29 <[1]fabio> how you do that, please?
18:13:37 <gyee> use /nick command
18:14:04 <topol> my chatzilla has a name pulldown next to the typing window
18:14:46 <ayoung> , so the only BPs tagged unstarted for H2 are
18:14:55 <ayoung> #link https://blueprints.launchpad.net/keystone/+spec/inherited-domain-roles
18:15:05 <ayoung> #action henrynash to update
18:15:19 <ayoung> and  	v3 Region API
18:16:00 <ayoung> which was jaypipes , blocked by termie but due to the fact he wanted to make sure the approach was general enough.
18:16:06 <ayoung> That review has lapsed
18:16:20 <atiwari> can we look https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition for H2?
18:16:27 <atiwari> has some API change
18:16:45 <gyee> #link https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition
18:17:31 <atiwari> mostly for roles API
18:17:42 <gyee> I like the service attribute approach
18:17:50 <ayoung> atiwari, are you wroking on it?
18:17:51 <gyee> service role attribute
18:18:17 <atiwari> yes, started the BP I can start soon
18:18:38 <atiwari> based on +1/+2
18:18:39 <gyee> ayoung, can we at least bless the BP first?
18:19:20 <gyee> we can hash out the design details
18:19:35 <ayoung> gyee, so role names should be global, so I can't say as I agree with that.  I think it shows a fundamental misunderstanding of how our RBAC is iplemented
18:19:52 <ayoung> it is groups that can come from different organizations, not roles
18:20:07 <atiwari> it will not impact RBAC
18:20:10 <ayoung> roles are to determine what perms a user has in a service, so that should be global
18:20:24 <ayoung> atiwari, I am specifically addressing the verbage in the BP
18:20:32 <gyee> ayoung, you are confusing role names with role IDs
18:20:57 <gyee> having role names global is inflexible
18:21:11 <gyee> just like we do away with having user names global
18:21:13 <ayoung> Ah, OK...He is saying specifically only per service.  I can get behind that
18:21:29 <gyee> correct, roles are service-specific anyway
18:21:34 <atiwari> sorry, if it is confusing
18:21:49 <ayoung> atiwari, nah, I;m just in too much of a rush and jumping to conclusions
18:22:31 <ayoung> OK, action Item, lets get some feedback on that BP
18:22:40 <gyee> sounds good
18:23:01 <ayoung> I can take a look after this meeting,  atiwari feel free to noodge me
18:23:08 <gyee> #action need feedback on https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition
18:23:10 <atiwari> ok
18:23:12 <ayoung> #action ayoung to review https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition
18:23:20 <atiwari> great
18:24:37 <gyee> ayoung, more more BP https://blueprints.launchpad.net/keystone/+spec/generic-signature-validation
18:24:51 <ayoung> OK...want to address a point on two patches I have out that are H2  https://review.openstack.org/#/c/33745/  and https://review.openstack.org/#/c/34254/  are prep for split id.  Both are alrage number of lines, but both should be failry trivial patches, as they are moving code around, not rewriting
18:25:26 <gyee> ayoung, will do that today
18:26:06 <topol> ayoung, will review them today as well
18:26:08 <ayoung> assignment backend in particular is nasty in gerrit, as tracking relocations is tough, as jamielennox points out. Feel free to ping me with questions
18:26:11 <gyee> both changes seem pretty trivial
18:26:14 <lbragstad> ayoung: forgot to put my +1 on https://review.openstack.org/#/c/33745/ my questions were answered
18:26:20 <ayoung> gyee, that was the goal
18:27:04 <ayoung> the final stage will be allowing assignments and ID to be separately configurable, which should be easier to understand than trying to mix it in with these patches.
18:27:05 <ayoung> OK...
18:27:14 <ayoung> Anything else for H2?
18:27:27 <gyee> #action code review https://review.openstack.org/#/c/34254/ and https://review.openstack.org/#/c/33745/
18:27:42 <topol> stevemar, is oauth for H2?
18:27:59 <ayoung> topol, yes
18:28:06 <stevemar> topol, ayoung, yeah - oauth is for h2
18:28:21 <ayoung> stevemar, I'd love it if oauth and trusts could use common code for the revocation issues I brought up
18:28:46 <ayoung> Ideally ,a "trust" would be the same table as "consumer"  I think
18:29:00 <stevemar> ayoung: i need more info on that before i agree to anything
18:29:03 <stevemar> :)
18:29:09 <fabioG> I am working on this BP as well: https://etherpad.openstack.org/havana-endpoint-filtering
18:29:16 <gyee> ayoung, but for oauth, consumer trust is established out-of-band right?
18:29:30 <ayoung> gyee, not really.  It is a separate web call
18:29:34 <ayoung> but it is inband
18:29:51 <ayoung> fabioG, good stuff, think you can haveboth ready for H2?
18:30:08 <fabioG> I think so
18:30:29 <fabioG> planning to get a review out end of the week
18:30:44 <fabioG> do I need to already merge the two or I can leave them separate for now?
18:30:49 <ayoung> fabioG, https://blueprints.launchpad.net/keystone/+spec/endpoint-filtering  is an auth_token middleware change, not a keystone change right?
18:31:02 <ayoung> middleware does not have to be in for H2
18:31:09 <fabioG> no is keystone
18:31:13 <gyee> ayoung, that's API level change
18:31:29 <fabioG> there are new APIs to link projects and endpoints
18:31:42 <fabioG> creating associations used to filter the catalog back
18:32:58 <ayoung> fabioG, I would think that the first step is : create a token that lists a single endpoint in its service catalog.  Then, on the middleware side, enforce that an token that comes in lists the current service in its catalog
18:33:15 <ayoung> simpler, and more likely to actually get finished
18:33:41 <ayoung> On the token creation side, allow adding an endpoint into the request
18:33:53 <fabioG> ayoung, code is 90% done
18:34:07 <ayoung> fabioG, that is no reason to accept a aptch, you realize
18:34:23 <bknudson> isn't all code always 90% done?
18:34:28 <fabioG> I know, is that I implemented following the current BP
18:34:31 <fabioG> specs
18:34:31 <ayoung> we have to make sure we are not over designing, and I thought this one was pretty clear when we discussed it
18:35:22 <ayoung> Now, allong a project/enpoint relationship is a valuable abstraction, but notnecessary for binding a token to an endpoint when enforcing it
18:35:27 <gyee> ayoung, we discussed it at the summit
18:35:29 <ayoung> those can be split
18:35:40 <gyee> pretty much everyone was nodding their head
18:36:09 <gyee> ayoung, enforcement comes from the client
18:36:15 <ayoung> gyee, there was also the jaypipes regions thing which was the other way of scoping endpoints
18:36:36 <ayoung> gyee, yes, enforcement comes from the client, which is not tied to H1
18:36:38 <ayoung> H2
18:36:40 <gyee> ayoung, no, jaypipes patch deals with endpoint lookup in the reverse order
18:37:02 <jaypipes> reverse order?
18:37:03 <gyee> like region->service->endpoint
18:37:11 <jaypipes> ah, yes... correct.
18:37:22 <ayoung> gyee, and this is project->service->endpoint
18:37:23 <fabioG> that is a catalog search
18:37:24 <jaypipes> with region == some amorphous container.
18:37:29 <gyee> I am totally fine with that
18:38:09 <gyee> endpoint-filtering deals with assigning endpoints to tenants and only return those assigned to the scoped tenant
18:38:40 <gyee> rather than returning the whole shebang, we only return the ones assigned to the tenant
18:38:44 <ayoung> #action review https://blueprints.launchpad.net/keystone/+spec/endpoint-filtering
18:39:03 <ayoung> gyee, OK,  so is anyone working  enforcement?
18:39:19 <gyee> ayoung, no need
18:39:42 <gyee> novaclient will reject the request if I can't get the endpoint from the service catalog
18:39:44 <ayoung> gyee, auth_token middleware will need to enforce that a token is scoped the the current service
18:39:47 <gyee> for example
18:39:57 <ayoung> gyee, we can't count on the clients being run
18:40:18 <ayoung> OK,  that can happen on separate cycle
18:40:27 <gyee> ayoung, yeah, you are right, we need to pass in the service ID for token validation
18:40:36 <gyee> ayoung, yeah, I agree
18:40:52 <ayoung> #action follow up on auth_token middleware enforcing endpoint scoping of tokens
18:41:06 <ayoung> #topic high priority bugs
18:41:54 <ayoung> #link 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%20Progress&field.status=Fix%20Committed&orderby=status&start=0
18:42:51 <ayoung> Downgrading the one marked incomplete, as there has been no feedback privded by the reporter, and it has not been seen elsewhere
18:43:11 <bknudson> ayoung: isn't there a priority above High? Critical
18:43:49 <ayoung> bknudson, yes, and there is nothing there that has not been tagged Fix released
18:44:10 <ayoung> bknudson, so the High bugs neeed to be triaged, and post H2, focus will shift to clearing out that list
18:45:00 <ayoung> #topic Unified Client authentication
18:45:07 <ayoung> OK, so this comes from my camp
18:45:25 <bknudson> this would help everyone
18:45:55 <ayoung> bknudson, yes.  In addition, we should standardize all clients to using the request library, and getting the SSL configuration solid
18:46:05 <gyee> +1
18:46:27 <bknudson> only question is... what's the status of the openstack client ?
18:46:43 <topol> stevemar????
18:46:47 <ayoung> bknudson, different question
18:46:48 <bknudson> we're saying we're not going to take new function in keystone.
18:46:59 <bknudson> are other projects the same?
18:47:00 <ayoung> this is making all of the current clients use keystoneclient as their auth library
18:47:04 <bknudson> so maybe we just do openstack client.
18:47:26 <bknudson> the python libs?
18:47:32 <bknudson> ayoung ^
18:47:38 <topol> wait I thought openstack client was the unified command client
18:48:07 <stevemar> topol: they're talking about unified client auth... i think it's different from what i'm working on
18:48:08 <topol> didnt we separate the goals
18:49:10 <topol> maybe I misunderstood bknudson when he said openstack client.... its what he said..
18:49:44 <ayoung> There was a ticket for making all of the clients use the requests library.  That was a first step
18:49:53 <bknudson> topol: one thing the CLIs don't do today is handle --domain for the usernames.
18:50:06 <ayoung> BTW, that is what https://review.openstack.org/#/c/34161/ is about
18:50:12 <ayoung> But hat tis middleware
18:50:39 <stevemar> bknudson: agreed...
18:52:00 <bknudson> httplib is part of python standard libs and requests is external?
18:52:01 <ayoung> The reason that review failed is, I think, requrest and PrettyHTML as a mocking library,  OPrttyHTML would need to be added to test-requires
18:53:27 <ayoung> bknudson, I think so,
18:53:42 <ayoung> but requests is identified as the Openstack client of choice
18:53:54 <bknudson> so somebody's using it already?
18:54:02 <ayoung> bknudson, keystoneclient is
18:54:39 <ayoung> bknudson,  https://github.com/openstack/python-keystoneclient/blob/master/requirements.txt
18:55:01 <bknudson> so some tests were using requests and others httplib...
18:55:05 <ayoung> One last item for review:  https://blueprints.launchpad.net/keystone/+spec/authentication-tied-to-token
18:55:07 <bknudson> ok, makes sense
18:55:32 <ayoung> Since ^^ is an API change, would like to get it blessed
18:56:08 <gyee> ayoung, that for m2?
18:56:09 <bknudson> ayoung: is this going to be required or optional?
18:56:18 <ayoung> bknudson, optional to start
18:56:28 <ayoung> bknudson, we are doing a graduated enforcement
18:56:31 <ayoung> 1. is ignored
18:56:33 <ayoung> 2 is optional
18:56:45 <ayoung> 3. is enforce if present
18:56:50 <ayoung> 4. is required
18:57:08 <bknudson> at some point, why not just use Kerberos?
18:57:55 <ayoung> bknudson, because Kerberos doesn't do authorization, just authentication
18:58:09 <ayoung> and yes I am aware of the extensions to Kerberos to do authZ
18:58:14 <ayoung> and service tickets
18:58:22 <gyee> and KDC has to stay up all the time right
18:58:35 <ayoung> bknudson, this is specifically tying authorization documents to authentication
18:58:39 <gyee> more dependency
18:59:04 <bknudson> so client provides a public key and that can get embedded in the token?
18:59:06 <ayoung> gyee, it can also be done with X509
18:59:20 <ayoung> So that decision is left to the deployment
18:59:33 <gyee> bknudson, yep, that's a possibility
18:59:36 <ayoung> bknudson, probably the cert finglerprint makes more sense for PKI
18:59:51 <ayoung> OK...1 minute left
18:59:57 <ayoung> #topic opendiscussion
19:00:00 <bknudson> ok, this makes sense.
19:00:01 <lcheng> ayoung, do you have permission to release a new version of keystoneclient? This is blocking the BP for v3 auth login in horizon.
19:00:16 <ayoung> lcheng, link?
19:00:37 <ayoung> lcheng, I don't think I do, think that has to be PTL
19:00:53 <ayoung> lcheng, ask at the release meeting tonight at 5
19:00:56 <ayoung> Easter
19:00:57 <ayoung> n
19:01:04 <ayoung> OK, we are over time
19:01:06 <lcheng> horizon bo: https://blueprints.launchpad.net/horizon/+spec/login-domain-support
19:01:12 <lcheng> ayoung, okay.
19:01:14 <ayoung> #endmeeting