18:07:49 <dolphm> #startmeeting keystone
18:07:51 <openstack> Meeting started Tue Oct  9 18:07:49 2012 UTC.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:07:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:07:53 <openstack> The meeting name has been set to 'keystone'
18:07:59 <dolphm> might as well make it official
18:08:12 <ayoung> O/
18:08:47 <gyee> \o
18:08:48 <dolphm> more officiality: any high priority bugs?
18:09:31 <ayoung> https://bugs.launchpad.net/keystone/+bug/1063852
18:09:32 <uvirtbot> Launchpad bug 1063852 in keystone "Default to PKI tokens" [High,In progress]
18:09:54 <ayoung> The goal was to switch to PKI day one so we get people beating on it all during the dev cycle
18:10:09 <ayoung> I had planned on submitting this earlier,  but there were a few issues to iron out first.
18:10:28 <dolphm> ayoung: i saw the build failures, is the 27 failure legit?
18:10:30 <ayoung> the --wrap change broke scripting,  and now that it is in for the keystone client
18:10:55 <boden> ayoung -- I did leave you a question in that bug... nothing urgent just a question
18:11:14 <ayoung> AssertionError: u'2012-10-10T17:12:13Z' != u'2012-10-10T17:12:14Z'
18:11:20 <ayoung> we really should fix that
18:11:41 <dolphm> yeah
18:11:48 <ayoung> boden, I
18:11:51 <dolphm> there's a bug for it, right?
18:12:22 <ayoung> 'll answer in the ticket, but the short is that devstack is set up to do it right, and the Packages will need to make their own decisions how to handle it
18:12:29 <ayoung> dolphm, I think so.
18:12:32 <dolphm> ayoung: boden: do we have docs instructing people to run keystone-manage pki_setup?
18:12:57 <ayoung> https://bugs.launchpad.net/keystone/+bug/1045962
18:12:58 <uvirtbot> Launchpad bug 1045962 in keystone "Transient test failure: test_token_expiry_maintained" [Low,Confirmed]
18:13:05 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1063852
18:13:06 <ayoung> I'll trigger a recheck
18:13:06 <uvirtbot> Launchpad bug 1063852 in keystone "Default to PKI tokens" [High,In progress]
18:13:18 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1045962
18:14:30 <ayoung> boden, the short of it for the packagers is that they probably need to call the keystone setup for PKI as the appropriate user
18:14:54 <ayoung> https://bugs.launchpad.net/keystone/+bug/1031372
18:14:56 <uvirtbot> Launchpad bug 1031372 in openstack-manuals "keystone-manage pki_setup creates certs owned by root" [High,Triaged]
18:15:00 <dolphm> ayoung: do you think packagers will use pki_setup or do a similar setup manually?
18:15:07 <dolphm> "manually"
18:15:16 <ayoung> dolphm, I would think pki_setup
18:15:38 <boden> ayoung -- ok, I'm still coming up to speed on openstack in general so some of my comments/questions may be obvious.. bare with me
18:15:48 <ayoung> the  thing is, the RPM approach still requires a post install configuration.  I don't think the deb approach does that
18:16:15 <dolphm> boden: that's a never-ending process :)
18:16:33 <ayoung> so,  for RPM,  it will be up to the end user to trigger it, or for the install script to trigger it
18:17:07 <ayoung> they might want to use a certificate signed by a pre-existing CA.
18:17:51 <boden> I was just typing that (existing CA)... I was expecting to see a set of docs on setting up PKI
18:18:54 <dolphm> boden: +1 i haven't seen any
18:19:01 <boden> just to confirm -- OpenStack does support PKI based tokens for Folsom right? I know the code is there, I'm just verifying its formally supported
18:19:08 <dolphm> #link http://docs.openstack.org/developer/keystone/configuration.html
18:19:13 <dolphm> would expect them there ^
18:19:42 <dolphm> in addition to an entry on http://docs.openstack.org/developer/keystone/man/keystone-manage.html
18:19:46 <ayoung> boden, yes
18:19:55 <ayoung> you need to enable it in the config file
18:20:56 <boden> ayoung, yep I've been running with with since you dropped it... I posted a blog on developer works this AM which very quickly talks about PKI, but I think we have a gap in the OpenStack docs
18:22:13 <ayoung> boden, please open a ticket, and we can use that to track the PKI docs changes required
18:22:20 <boden> will do
18:23:20 <dolphm> ayoung: boden: already opening one, will link in a second
18:24:53 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1064585
18:24:54 <uvirtbot> Launchpad bug 1064585 in keystone "Docs missing for keystone-manage pki_setup" [Undecided,Confirmed]
18:25:50 <zykes-> is there a plan to introduce more like "organizational" tenant structures in keystone ?
18:26:02 <zykes-> since ya'll here
18:26:11 <dolphm> #topic open discussion
18:26:23 <dolphm> zykes-: yep!
18:26:31 <gyee> ayoung, should you be adding openssl to pip-requires?
18:26:38 <zykes-> dolphm: v3 api @ grizzly or ?
18:26:47 <dolphm> zykes-: yep https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md
18:27:07 <zykes-> how's permissions then dolphm ?
18:27:10 <zykes-> better then today or ?
18:27:15 <dolphm> zykes-: the official spec ^ see Domains & Projects
18:27:17 <ayoung> gyee, yes
18:28:03 <zykes-> V2 is gonna be a wanted piece!
18:28:10 <dolphm> zykes-: v3 also includes centralized policy repository, and the proposed implementation of the v3 api includes full RBAC
18:28:21 <zykes-> will you be able to implement it all during G ?
18:28:55 <dolphm> zykes-: a lot of it is already implemented https://review.openstack.org/#/q/is:watched+status:open+branch:feature/keystone-v3,n,z
18:28:59 <dolphm> zykes-: just needs review :)
18:29:08 <zykes-> oh
18:29:22 <zykes-> Do you know how KS will play in the "Cell" game of nova ?
18:30:15 <ayoung> zykes-, probably the first pass will be to assign cells to tenants
18:30:21 <ayoung> or probably more correct
18:30:34 <ayoung> setup cell/tenant access
18:30:40 <dolphm> ayoung: cell/project*
18:30:51 <zykes-> why a ccell to a project ?
18:30:59 <dolphm> zykes-: v2 tenants = v3 projects
18:31:00 <zykes-> isn't a cell kinda a zone today ?
18:31:13 <gyee> domain?
18:31:29 <ayoung> zykes-, a project needs access to the resources scoped within a zone.  THen, users assigned to that project can use those resources
18:31:35 <dolphm> zykes-: i believe they just chose a new name for zones, right?
18:32:27 <zykes-> ah
18:32:37 <zykes-> dolphm: isn't that a "Cell" ?
18:32:50 <dolphm> zykes-: i think so
18:35:05 <boden> I did want to discuss the topic I posted on the meeting wiki when you guys are done with this topic
18:35:12 <boden> the topic I posted was "Pluggable authN: Apache proxy vs pluggable python handlers -- which to support (or both)."
18:35:50 <ayoung> boden, pluggable authN separate from the identity database?
18:35:59 <ayoung> I can understand pluggable authZ
18:36:16 <ayoung> OK,  I have that backwards
18:36:25 <ayoung> authZ authorization
18:36:40 <ayoung> should be driver from Identity backend
18:36:54 <boden> ayoung we had kicked this one around quite a bit on the email list...
18:36:56 <ayoung> pluggable authN...why try to do something more than apache for starters
18:37:01 <dolphm> authz is the policy driver
18:37:08 <boden> and I formulated the following blueprint: https://blueprints.launchpad.net/keystone/+spec/pluggable-identity-authentication-handlers
18:37:36 <boden> however the direction in some of the emails indicated we should add HTTPD support instead and use authorization via apahae
18:37:51 <boden> s/apahae/apache/g
18:37:57 <ayoung> so I would almost see this as mod_auth_x  for eventlet.  Why put in that effort?
18:38:40 <boden> I know nothing about mod_auth_x for eventlet, so I can't really provide my 2 cents until reading about it
18:38:42 <ayoung> boden, I'm not saying "no" I am just looking for the justification
18:39:06 <boden> btw -- my background is mainly in J2EE... so I've only been pythonic for about 4 months (FYI)
18:39:21 <ayoung> boden, I mean it sounds like implementing the various apache HTTPD mod_auths but for Eventlet
18:39:35 <ayoung> boden, yeah,  I come from a similar background
18:39:54 <ayoung> so in JEE the auth is done by the container, separate from the application
18:40:03 <ayoung> Tomcat Realms etc
18:40:22 <boden> ayoung -- so in the email list both myself and someone else responded to the thread stating we thought there is benefit in having 'basic' authN handlers via python.. let me find the thread
18:40:29 <ayoung> in HTTPD, it is done by modules.  You can do the same thing where you front Tomcat with Apache, and let it do the authN for you
18:41:26 <boden> so if you read this response http://lists.openstack.org/pipermail/openstack-dev/2012-October/001491.html
18:41:32 <dolphm> ayoung: boden: the ultimate goal is just to support http basic/digest, correct?
18:41:57 <dolphm> i feel like we're talking about solutions when we never talked about the problem
18:42:00 <dolphm> but maybe i missed that
18:42:15 <ayoung> boden, yes,  but still looking for justification.  That just says "we want it"
18:42:23 <ayoung> dolphm, +1
18:42:38 <boden> so I think the problem was stated in the blueprint to some degree
18:42:54 <ayoung> so,  what I would suggest is that whatever code we write in this effort, it is with an eye to upstream eventlet
18:43:22 <boden> there are 3 bullets in the bp which describe what I see as the main problem
18:43:29 <ayoung> it should not be Keystone specific, and it shouldbe usable by other people that want eventlet,  such as the other Openstack projects
18:44:41 <dolphm> boden: are we talking about bypassing the rest api? or putting something in front of the rest api that speaks http basic/digest and translates that into regular api requests?
18:44:42 <boden> ayoung, I guess I'm not following why other OS projects need support for authentication -- they do that based on the token in the users request
18:44:45 <ayoung> boden, there is a good argument for basic-auth done in eventlet, if only as a testing mechanism for keystone
18:45:06 <zykes-> what's a entity ?
18:45:15 <dolphm> zykes-: v3 spec?
18:45:19 <ayoung> boden,  just because we tie people to keystone doesn't mean people might not want to use it.
18:45:27 <zykes-> dolphm: looking there yes :p
18:45:37 <dolphm> zykes-: "The examples in this section utilize a resource collection of Entities on /v3/entities which is not actually a part of the Identity API, and is used for illustrative purposes only."
18:45:56 <zykes-> ok
18:46:34 <ayoung> boden, so I don't see a need for the keystone code to know about anything other than REMOTE_USER/external, but I can see a use for eventlet specific code for authN. Is there a need for anything beyond that?
18:46:38 <boden> ayoung so your're suggesting if its done in python land (rather than via Apache auth) it might be something like a python paste middleware?
18:46:42 <dolphm> zykes-: are you reading my github, or openstack's?
18:46:47 <ayoung> boden, yes
18:47:20 <zykes-> dolphm: the one you linjked :()
18:47:28 <dolphm> zykes-: i linked both
18:47:32 <dolphm> zykes-: is my name in the url? lol
18:47:39 <ayoung> 13 minutes left.
18:47:56 <ayoung> boden, feel free to continue this discussion with me after, if you still need clarification
18:48:00 <zykes-> ok :)
18:48:00 <boden> ayound I can see a case for a pluggable authN handler to want a reference to the actual identity driver... however there are a number of solutions to that
18:48:27 <ayoung> dolphm, last open topic:  should I push to have the schedule changed, or just accept my fate?
18:48:42 <dolphm> ayoung: totally your call
18:48:45 <boden> ayoung -- discussion here in RTC, or you mean off-line via email
18:48:52 <dolphm> ayoung: sooner the better for schedule changes though
18:49:04 <ayoung> boden, yeah,  basic-auth + SQL  basic-auth+LDAP  would work in middleware pieces,
18:49:13 <dolphm> boden: i'd like to at least follow the conversation, however ya'll proceed
18:49:18 <ayoung> boden, openstack-dev or pm,  either is fine
18:49:35 <boden> sorry... pm == ?
18:49:39 <ayoung> private message
18:49:45 <dolphm> irc direct message?
18:49:56 <ayoung> openstack-dev is fine
18:50:05 <ayoung> #openstack-dev that is
18:50:32 <boden> ok -- we might have to take this up tomorrow... I have a hard stop at the top of the hour
18:51:08 <dolphm> ayoung: review some identity-api stuff for me when you get a chance :) i have a stack of commits i need to propose after those merge
18:51:20 <dolphm> zykes-: you too ^ :P
18:51:30 <ayoung> dolphm, in the V3 code base? Sure
18:52:05 <dolphm> ayoung:  https://review.openstack.org/#/q/is:watched+status:open+project:openstack/identity-api,n,z
18:52:11 <dolphm> ayoung: identity-api repo
18:52:23 <ayoung> dolphm, everything on my todo list is reviewed. Nothing on the link you just posted
18:52:43 <dolphm> ayoung: add openstack/identity-api to your watch list
18:52:45 <dolphm> ayoung: https://review.openstack.org/#/q/status:open+project:openstack/identity-api,n,z
18:53:47 <gyee> dolphn, we use md in identity-api, but rst in keystone?
18:53:48 <ayoung> dolphm, you can always add me as a reviewer.  That will help me prioritize, too
18:53:58 <gyee> dolphm
18:54:03 <zykes-> dolphm: sorry ?
18:54:08 <dolphm> gyee: yeah... apparently its easier to publish
18:54:13 <gyee> i c
18:54:38 <dolphm> gyee: *shrug* i didn't have a preference between them, but i hate switching back and forth... i end up writing md in rst docs, and rst in md docs lol
18:54:48 <ayoung> dolphm, OK,  I'm a watching
18:54:53 <gyee> haha, same here
18:54:53 <dolphm> ayoung: will do
18:54:56 <dolphm> ayoung: thanks
18:55:37 <zykes-> dolphm: what you wanted me to do ?
18:55:41 <ayoung> dolphm, Imma -2 anything in passive voice, just so you know.
18:55:47 <dolphm> ayoung: awesome
18:55:52 <ayoung> no, not really./
18:55:57 <dolphm> ayoung: for serious
18:56:24 <ayoung> dolphm, 		Users can be associated with zero or more projects
18:56:35 <ayoung> This attribute is provided by the
18:57:02 <ayoung> you sure you want me to do that?
18:57:17 <zykes-> What is "facing" ?
18:57:19 <dolphm> ayoung: absolutely, let's make it consistent
18:57:29 <dolphm> zykes-: that's been renamed to "interface"
18:57:41 <dolphm> zykes-: "admin" "internal" or "public"
18:57:53 <dolphm> zykes-: essentially the network interface the endpoint sits on
18:58:11 <zykes-> hmm k
18:58:54 <dolphm> zykes-: the analog in the current api is <endpoint adminURL="http://..." publicURL="http://..." internalURL="http://..." />
19:00:12 <dolphm> #endmeeting