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