18:00:31 <henrynash> #startmeeting keystone
18:00:32 <openstack> Meeting started Tue Jul  2 18:00:31 2013 UTC.  The chair is henrynash. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:35 <openstack> The meeting name has been set to 'keystone'
18:00:36 <henrynash> ahh!
18:00:57 <henrynash> dolphm is off, so is ayoung, I think
18:01:25 <topol> who's the commanding officer??? Ain't it you Henry?
18:01:34 <henrynash> I believe 'tis me
18:01:35 <gyee> is anyone know if Malini still working on key manager?
18:01:50 <henrynash> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting
18:02:16 <henrynash> ( some of this is hang over from last time, not updated i expect)
18:02:17 <atiwari> gyee: I dropped her an email did not get any response
18:02:42 <henrynash> Reminder: Havana milestone 2 cut & API-level feature freeze July 16th
18:02:56 <henrynash> Reminder: Start using the SecurityImpact tag in gerrit
18:03:02 <bknudson> dolph seemed to indicate API freeze is only for core, not extensions
18:03:18 <stevemar> bknudson: yeah, i was under the same impression, saw that in his email
18:03:27 <gyee> bknudson, I thought he meant both
18:03:37 <gyee> at least from the last meeting
18:03:39 <henrynash> bknudson: so originally he told me that it DID include extensions, but recent email suggest that this is replaced
18:03:48 <bknudson> maybe he's finally resigned to reality.
18:04:04 <gyee> total recall
18:04:20 <henrynash> #topic High priority bugs or immediate issues?
18:04:27 <bknudson> he probably thinks he's involved in a plot on mars right now.
18:04:57 <henrynash> any burning issues?
18:05:19 <gyee> code review? I need to catch up on that too
18:05:45 <henrynash> #topic High priority code reviews - aimed at H2
18:06:23 <stevemar> its already on the list, but delegated_auth is ready for code review
18:06:41 <henrynash> so I have one for sure that I am trying to get in https://review.openstack.org/#/c/34611
18:06:43 <gyee> stevemar, that includes both keystone and keystone client right?
18:06:46 <stevemar> gyee ^ if you have free time
18:06:55 <topol> henrynash I will review it today
18:07:13 <henrynash> stevemar: it's an extension, right?
18:07:17 <stevemar> gyee: yeah, just search for stevemar as owner: or ping me and i'll give you links.
18:07:21 <stevemar> henrynash: yes
18:07:32 <gyee> k, will get on them
18:08:02 <fabio> catalog opt out: https://review.openstack.org/#/c/33188/
18:08:02 <henrynash> steveamr: so great for H2 if we can, but would be allowed for H3 (according to latest guidance)
18:08:57 <stevemar> henrynash: yeah, hoping for H2
18:09:00 <henrynash> fabio: is there an api spec change that goes with that?
18:09:13 <henrynash> stevemar: H2 is always better than H3 1
18:09:15 <henrynash> !
18:09:28 <fabio> spec changes: https://review.openstack.org/#/c/34478/
18:09:46 <fabio> I also have done the spec change and code for the endpoint filtering bp
18:10:04 <fabio> specs: https://review.openstack.org/#/c/34489/
18:10:21 <fabio> code: https://review.openstack.org/#/c/33118/
18:10:35 <henrynash> fabio: we really need the api's agreed asap if this is going in to H2
18:10:47 <fabio> I agree
18:11:08 <fabio> so far I incorporated all the suggestions
18:11:09 <henrynash> fabio: I don't see a new version of the api posted after comments from Brant
18:11:24 <fabio> I will push them in the early aft
18:11:47 <fabio> are we ok in using the query string?
18:11:55 <fabio> for opting out of the catalog?
18:12:04 <henrynash> #action review new versions of  https://review.openstack.org/#/c/34478/ and https://review.openstack.org/#/c/34489/
18:12:29 <gyee> +1 for query string
18:12:33 <bknudson> seems weird to use a query string but I'm ok with whatever others want.
18:12:54 <gyee> for a GET function, query string is RESTi
18:13:04 <bknudson> it's not GET, it's POST
18:13:17 <gyee> oh
18:13:47 <bknudson> we've already got the body to provide all the options, so why spread them around to the query string.
18:13:52 <gyee> wait, that authenticate or validate?
18:14:11 <bknudson> there's no validate... https://blueprints.launchpad.net/keystone/+spec/catalog-optional
18:14:49 <bknudson> unless we were discussing another use of query options something else?
18:15:11 <gyee> bknudson, yeah, I am ok with having it in the request body
18:15:29 <atiwari> gyee: +1
18:16:00 <topol> +1 on request body
18:16:05 <henrynash> #action fabio: wok with bknudson and gyee to update api
18:16:19 <henrynash> #action fabio: work with bknudson and gyee to update api
18:16:50 <henrynash> ok, any other key H2 api changing reviews needed?
18:17:09 <atiwari> any thought about https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition
18:17:17 <atiwari> for H2
18:17:42 <gyee> I like the service-role relationship
18:18:00 <henrynash> atiwari: so if it is going to be accepted for H, it must be in for H2…
18:18:21 <atiwari> ok
18:18:22 <bknudson> unless we provide it an extension in H?
18:18:30 <bknudson> "it as an extension"
18:18:32 <henrynash> bknudson: agreed!
18:18:44 <gyee> I am fine with extension
18:18:45 <atiwari> no, I am looking for core
18:18:54 <bknudson> It can be core in I
18:18:54 <atiwari> please see my comments in etherpad
18:19:36 <henrynash> atiwari: link?
18:19:45 <gyee> #link https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition
18:19:59 <atiwari> #link https://etherpad.openstack.org/serviceid-binding-with-role-definition
18:20:46 <henrynash> atiwari: what about the comment about: How is this exposed to auth_token (and similar clients)?
18:21:29 <atiwari> auth_token or auth middle ware ?
18:21:42 <atiwari> I added my response over there
18:21:44 <henrynash> atiwari: both
18:21:44 <gyee> service_id is in the roles
18:22:12 <atiwari> and the token with have the service_id: role info
18:22:14 <henrynash> ok, so right now we return a list of role_names in a token
18:22:24 <atiwari> correct
18:22:39 <atiwari> later it will be ({service_id:"Swift","role":"Admin"}
18:22:57 <atiwari> Swift === 1234
18:23:03 <henrynash> atiwari: so every project will have to change how it process tokens to pass them to their policy engines?
18:23:30 <gyee> henrynash, no, policy engines only knows role names
18:23:31 <atiwari> no
18:23:40 <gyee> service ID is a filtering mechanism
18:23:52 <atiwari> there will abosolutly no change for service
18:24:06 <gyee> auth_token -> filtered by service ID -> RBAC
18:24:19 <henrynash> gyee: any who does the filtering?
18:24:29 <gyee> henrynash, middleware/client
18:24:44 <atiwari> service will consume roles the way they do it right now
18:25:37 <henrynash> gyee, antiwar: so I am just nervous about changing our token format
18:25:54 <gyee> define nervous :)
18:26:04 <henrynash> (antiwar->atiwari !)
18:26:16 <topol> nervous = people coming after us with torches and pitchforks
18:26:39 <atiwari> may be we can un touch the token for H time frame
18:26:49 <gyee> topol, in that case, all you have to do is change your username, like lopot :)
18:27:01 <atiwari> lets make it in core and in I time we will change token
18:27:11 <topol> yeah, that'll keep me safe. no one will see thru that
18:27:16 <henrynash> gyee: so I'll admit I don't have the history to fully understand how all the projects extract info from the token
18:27:20 <gyee> unless you username is bob
18:27:25 <bknudson> people around here know how to find topol
18:27:57 <gyee> henrynash, service ID used to be part of role definition, prior to KSL
18:27:59 <henrynash> gyee: udneratnd how auth middleware works, sure
18:28:18 <henrynash> gyee: KSL?
18:28:27 <gyee> Keystone Light
18:28:28 <henrynash> ahh, keystone liygt
18:29:20 <bknudson> still not sure why this can't be an extension for H
18:29:34 <atiwari> henrynash: auth middle ware will filter only those roles which are need to the service which middle ware is serving to
18:29:38 <henrynash> bknudson: I'd certainly lean that way
18:30:08 <gyee> atiwari, any reason why it can't be an extension to start with?
18:30:28 <gyee> it would certainly make henrynash feel less nervous
18:30:45 <henrynash> gyee: and I always appreciate that :-)
18:30:59 <atiwari> I don't see any side effect of having it in core
18:31:10 <atiwari> as it is backward compatible
18:31:37 <atiwari> what I am saying is in first phase let s not touch our token
18:32:11 <gyee> atiwari, but can it be an extension, rather than it must be core
18:32:11 <bknudson> how do we not change the token?
18:32:15 <henrynash> atiwari: I also see the issue that as core you have 14 days to get it all agreed, implemented, merged with all the other high priority items hitting in the next 14 days
18:32:28 <topol> +1 on starting as an extension
18:32:48 <atiwari> yes, that is the real challenge
18:32:58 <bknudson> auth_token isn't going to know what to do if there's nothing new in the token.
18:33:38 <atiwari> let's take it for ext
18:33:51 <atiwari> how about that ?
18:33:55 <henrynash> ok, I think tha's the best approach
18:33:56 <gyee> +1
18:34:22 <atiwari> good
18:34:31 <henrynash> #action antiwar to re-propose serviced role extensions as an extension for H
18:35:39 <henrynash> fyi on other H2 items, I do plan to try and get the OS-INHERIT extension in, but if it slips to H3 then so be it
18:35:59 <henrynash> anything else on H2?
18:36:40 <henrynash> #topic client unification and identity v3 support
18:37:03 <henrynash> this is ensuring we have support for our v3 apis in other cli clients
18:37:25 <henrynash> the keystone client v3 auth stuff is all in now
18:37:35 <bknudson> do the other clients have the same policy to use unified cli as keystone?
18:37:57 <henrynash> bknudson: you mean use openstackclient?
18:37:59 <bknudson> I tried using openstack cli the other day and couldn't figure it out.
18:38:13 <bknudson> henrynash: yes, the openstackclient.
18:38:31 <bknudson> I should have said the other projects (nova, glance, etc)
18:38:41 <gyee> bknudson, but what about at the lib level
18:38:50 <henrynash> bknudson: so I'd hope so….but have to admit I don't see much action in that direction
18:38:57 <bknudson> are we talking about the lib or the clis ?
18:39:20 <gyee> both I suppose
18:39:26 <bknudson> we're probably going to need the libs to use keystoneclient auth first...
18:39:26 <gyee> have to be consistent
18:39:29 <henrynash> bknudson: so we need clis that support v3 (which means we wan them to use our v3 libs, of coriuse)
18:39:55 <bknudson> the libs seems like the place to start.
18:40:07 <gyee> yes
18:40:15 <henrynash> bknudson:…and I think our libs are in good shape now, no?
18:40:45 <gyee> is keystoneclient fully implemented the V3 API set?
18:41:04 <bknudson> seems like this is something the core members of keystone should know...
18:41:08 <bknudson> but I don't.
18:41:14 <henrynash> gyee: I believe so…we pushed a bit change in a week or tow ago
18:41:28 <henrynash> ..pushed a big change...
18:41:41 <bknudson> support for v3 auth was the recent change.
18:41:48 <bknudson> seems important for keystone
18:42:14 <bknudson> but this is what the other client APIs would need to use.
18:42:23 <gyee> lets comb through the keystoneclient code to see if we have all the core APIs at least
18:42:28 <henrynash> bknudson: exactly
18:43:18 <henrynash> bknuson: there was some uncertainly last time I raised this as to whether the other clis (nova, dance) etc, use our client libs….I was told they did
18:43:48 <bknudson> my understanding is that they don't, but I didn't look into it.
18:44:03 <topol> wasnt there an email that did an inventory of this?
18:44:04 <henrynash> …in which case the task for them is sot switch to the v3 client libs and update the cli options so users can specify things like domains
18:44:10 <topol> they were like all different
18:44:52 <bknudson> the clis should also all use the same "library" for the auth options.
18:45:10 <bknudson> (provided by python-keystoneclient, maybe)
18:45:24 <tiamar> glanceclient implements keystoneclients, the others dont
18:45:25 <henrynash> #action cores: to do a quick check of the keystoneclient lib…see if you can spot anything missing
18:45:33 <gyee> bknudson, looking at novaclient code, they seem to support auth plugins
18:46:26 <henrynash> gyee, timar: i would think nova and glance would be our #1 and #2 targtes
18:46:36 <gyee> henrynash, make sense
18:47:09 <henrynash> tiamar: do you work with the glance client?
18:47:46 <bknudson> At the end of this, we would expect to be able to do something like "nova --user-domain=mydomain --user=bknudson --password=mypassword list"  , for example
18:47:48 <henrynash> tiamar: as in familiar with the code and contributors
18:47:58 <henrynash> bknudson: yep
18:48:13 <tiamar> henrynash, we did an internal job to the clients authenticate using keystone v3
18:48:16 <gyee> that bakes a question, why keystoneclient not part of oslo then?
18:48:29 <gyee> if that's a common integration point
18:48:37 <topol> gyee +1
18:48:40 <tiamar> henrynash, : i'm not familiar
18:49:33 <henrynash> gyee: interesting
18:49:56 <bknudson> python-keystoneclient is already a library... not sure why it needs to be an oslo libarary?
18:50:23 <gyee> bknudson, what is oslo then?
18:50:38 <bknudson> https://pypi.python.org/pypi/python-keystoneclient
18:50:55 <bknudson> https://pypi.python.org/pypi/oslo.config/1.1.1
18:51:12 <gyee> I mean functionally
18:51:23 <bknudson> oslo provides their common libraries, and then there's oslo-incubator
18:51:33 <gyee> "common"
18:51:47 <bknudson> like oslo.config is a common library
18:51:48 <henrynash> so pretty sure for H, we won't change this
18:51:57 <henrynash> the path we were on was:
18:52:23 <henrynash> 1) we would release new version of python-keystone client that contained the new v3 auth
18:52:49 <henrynash> 2) we would work with the other project clis to use the client lib
18:52:57 <henrynash> £
18:53:17 <bknudson> join the euro-zone already
18:53:26 <topol> :-)
18:53:29 <henrynash> #action henry-nash to follow up on status of this and discuss with other cli leads
18:53:43 <henrynash> (oops, not sure where the money came from!)
18:53:44 <gyee> so just the v3 auth apis, not the whole shebang
18:54:07 <topol> I could use some sterling guvnah
18:54:11 <henrynash> gyee: well would the other apis ever get used by another cli?
18:54:27 <gyee> probably not
18:54:37 <bknudson> the openstack cli uses the libs
18:54:40 <gyee> so does it make sense for v3 auth to be in oslo?
18:55:02 <topol> gyee, why wouldnt it?
18:55:16 <topol> its common right? Or we want it to be common
18:55:23 <gyee> topol, it should
18:55:36 <gyee> the common crypto stuff is already there
18:55:46 <henrynash> gyee: that would makes some sense, just the v3 auth part
18:56:01 <gyee> https://review.openstack.org/#/c/28471
18:56:05 <gyee> auth should be there as well
18:56:57 <henrynash> anyone have a reason why v3 auth shouldn't be in oslo
18:57:04 <bknudson> that's a good candidate for the SecurityImpact tag.
18:57:31 <bknudson> I don't see what we gain by putting it in oslo... they can already access it in python-keystoneclient.
18:57:53 <bknudson> are we saying oslo-incubator ?
18:58:17 <bknudson> If we put it in oslo-incubator, now we have to go through the work of importing it into all the other projects
18:58:18 <gyee> openstack.common.auth
18:58:41 <gyee> consistency, common integration point, stable interface (hopefully)
18:58:50 <henrynash> gyee: hmm, so that's different
18:58:55 <henrynash> OK, 2 mins to go
18:59:04 <bknudson> There's probably other keystoneclient function that should go in a common location...
18:59:09 <bknudson> service catalog handling
18:59:14 <henrynash> #topic open discussion (!)
18:59:20 <gyee> bknudson, sure
18:59:30 <gyee> I think catalog should be there as well
18:59:35 <gyee> catalog parsing
19:00:19 <henrynash> I think we'll have to continue that discussion elsewhere
19:00:24 <henrynash> #endmeeting