18:02:18 <heckj> #startmeeting keystone
18:02:19 <openstack> Meeting started Tue Feb 12 18:02:18 2013 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:22 <openstack> The meeting name has been set to 'keystone'
18:02:26 <heckj> who's around?
18:02:36 <topol> topol is here
18:02:38 <henrynash> heckj: hi
18:02:48 <kwss> hello
18:02:51 <stevemar> heckj: hello
18:03:06 <heckj> excellent! Welcome all
18:03:08 <spzala> Hello!
18:03:18 <heckj> grabbing up the agenda
18:03:41 <heckj> pretty stock - agenda at #link http://wiki.openstack.org/Meetings/KeystoneMeeting
18:03:54 <heckj> ayoung? dolphm? either of you around?
18:03:56 <topol> heckj, I had a quick question that I wanted to add to the agenda. Sent it to dolphm but forgot to send to you
18:04:08 <heckj> topol no problem - whatcha got?
18:04:10 <dolphm> i'm here
18:04:34 <heckj> #topic burning issues
18:04:38 <dolphm> topol: you should be able to edit the agenda with a wiki account
18:05:10 <heckj> topol: in the future, please do edit the agenda - common place to keep us organized
18:05:18 <topol> dolphm, another newbie error by me. will do that next time.
18:05:22 <heckj> Anything top on the list?
18:05:34 <dolphm> heckj: just review! review! review!
18:05:41 <heckj> gyee: last time, this was almost entirely focused on auth API - you good?
18:05:46 <heckj> heh
18:05:46 <topol> my question was regarding my devstack keystone ldap identity driver work
18:05:51 <topol> So in keystone.conf I set user_attribute_ignore = tenant_id,tenants,enabled and this allowed me to now successfully add a user using the ldap backend. My question is for getting keystone ldap to work from devstack should we just do this or am I hiding stuff under the rug and we really need to store the enabled attribute and thus we should add an extra objectClass to address this?
18:05:57 <gyee> heckj, yeah
18:06:07 <gyee> making good progress, https://review.openstack.org/#/c/21487/
18:06:10 <heckj> topol: cool, we'll come back to that
18:06:11 <gyee> missing tests and doc
18:06:23 <gyee> I am working on the tests at the moment
18:06:50 <dolphm> topol: i think we'd definitely prefer a place to store it, especially in tests
18:06:57 <heckj> #topic blueprint statii
18:07:15 <heckj> We have grizzly-3 milestone coming up in just over a week - that's the feature freeze time
18:07:20 <heckj> #link http://wiki.openstack.org/GrizzlyReleaseSchedule
18:07:34 <dolphm> i believe the last piece of bp default-domain is gating right now
18:07:45 <heckj> dolphm: excellent
18:08:10 <gyee> 9 more days!
18:08:12 <topol> I have free cycles to review stuff so let me know what is most critical
18:08:26 <heckj> gyee: pluggable authn also coming in with the API implementation?
18:08:29 <henrynash> heckj: …and that same change includes all the domain-scoping prep work…so ready to plug into v3 auth
18:08:45 <gyee> heckj, yes, there are 3 bps in there
18:08:48 <dolphm> topol: anything that's not specifically a bug
18:09:05 <topol> dolphm: Will do!
18:09:12 <dolphm> gyee's review is definitely most critical of all
18:09:25 <heckj> for all - the thing that will make this next week go the most smoothly with be consistent and clear reviews. If you can, please look over the list daily and update any that you see.
18:09:38 <dolphm> heckj: +10
18:09:41 <henrynash> heckj: on domain name spaces, we agreed the spec change…and the good news is that the work on top of the domain-scoping is really just to ensure name uniques constraints are set right
18:09:45 <topol> will do Gyees today
18:10:30 <heckj> Anyone know status from ayoung on token trusts and the replacement of tenant-membership with role?
18:11:01 <heckj> link for reviews: #link https://review.openstack.org/#/q/status:open+keystone,n,z
18:11:35 <henrynash> heckj: review is up, not quite there…I did suggest an alternative approach to what he is doing that *may* be simpler (its a comment on his review)
18:12:34 <henrynash> see my comment to patch 4: https://review.openstack.org/#/c/21327/
18:12:42 <heckj> kk
18:13:10 <dolphm> heckj: would love to get tenant-membership refactor in ASAP, and ayoung said he was going to tackle the identity-api for trusts related changes as well
18:14:18 <heckj> Okay - I've got what I need to update for the release meeting anyway.
18:14:23 <heckj> #topic Topol's LDAP question
18:14:29 <dolphm> ayoung is also blocking bp additional-endpoint-metadata which is just a giant nice-to-have for grizzly -- not sure how to resolve his concern
18:14:29 <henrynash> dolphm: take a look at my suggestion on tenant-membership….I may be missing something
18:14:35 <heckj> topol said: So in keystone.conf I set user_attribute_ignore = tenant_id,tenants,enabled and this allowed me to now successfully add a user using the ldap backend. My question is for getting keystone ldap to work from devstack should we just do this or am I hiding stuff under the rug and we really need to store the enabled attribute and thus we should add an extra objectClass to address this?
18:14:41 <dolphm> bp additional-endpoint-metadata  https://review.openstack.org/#/c/20075/
18:14:53 <dolphm> heckj: will do
18:15:39 <dolphm> heckj: topol: i imagine we want to A) have a conventional way to store the enabled attribute, B) demonstrate that convention in devstack
18:15:52 <topol> so enabled is giving me trouble for both add user and add tenant
18:16:23 <dolphm> topol: how so?
18:17:04 <topol> Both do not currently include an objectclass that has a good place to map the enabled value to that i know of
18:17:37 <topol> for AddUser what attribute of InetOrgPerson should I use for enabled?
18:18:34 <dolphm> topol: do you have a suggestion for what to use?
18:18:37 <dwchadwick> You can invent your own boolean attribute and object class, call it a Keystone related name
18:18:45 <topol> Same question for addTenant
18:19:16 <topol> Was hoping folks knew of an existing one. Otherwise I will invent my own. But wanted to check with you all first
18:19:29 <dwchadwick> Eg. Enabled attribute syntax boolean. Keystone Object class must contain Enabled attribute
18:19:48 <dolphm> topol: i'd say invent your own and work it out in code review, if anyone has a better solution
18:20:44 <topol> K. I will do it as dwchadwick recommends.  I'll open it as a bug on devstack cause thats where my changes will go.  THANKS!
18:20:48 <dolphm> (i'm stepping away from my desk for now -- will hopefully be back before the official meeting end time)
18:21:17 <heckj> topol: sounds like a plan.
18:21:45 <heckj> #topic keystoneclient or openstackclient support
18:22:05 <henrynash> heckj: I put this on
18:22:05 <heckj> Not sure who/what this topic is specifically about - anyone have th detail?
18:22:10 <heckj> All yours
18:22:35 <henrynash> just wanted to get some clarity…we have Steve on I think who is working on adding v3 cli support
18:23:06 <stevemar> yes, currently adding v3 support to openstackclient
18:23:09 <henrynash> the intention had been to do this in the openstackclient , rather than update the keystone specific cleint
18:23:47 <henrynash> …put impression from Dean is that the openstackclient is on a different schedule, maybe not be shipped with the main Girzzly release etc.
18:24:03 <henrynash> did we get the correct impression, or did we misread that?
18:24:14 <heckj> you got the correct impression.
18:24:37 <henrynash> hence…do we need a cli v3 client for keystone at Grizzly release?
18:24:44 <heckj> The clients in general are all on their own cycle, with the intention (unfortunately, more than the reality) that they always maintain backwards compatibility
18:25:30 <heckj> We *don't* need it - but it would be nice. At a minimum, I we need keystoneclient to support the same V3 auth, but that's more about our integration testing across both sides than an otherwise specific need.
18:25:33 <henrynash> heckj: would it be beneficial if we gave the keystone client some v3 cli capability?
18:25:38 <gyee> phew! I was think we have to hookup the auth apis for keystoneclient by 21st :)
18:25:40 <heckj> That said, we won't get uptake without clients supporting the API
18:25:58 <heckj> henrynash: absolutely
18:26:15 <heckj> gyee: you may find you have to anyway to do the full cycle testing
18:26:18 <henrynash> heckj: so Steve and others are ready to pitch in and try and add this to keystone client if this would help
18:26:42 <heckj> we won't be able to get V3 enabled in devstack until the client fully supports it, and that will be the next large critical step to getting it accepted as the new API
18:26:43 <gyee> I can definitely use some help on the keystoneclient side
18:27:01 <gyee> right now I am just adding tests for keystone only
18:27:01 <heckj> henrynash: stevemar: that help would be very, very welcome!
18:27:07 <stevemar> gyee: i'm able and willing
18:27:09 <topol> gyee, we will have Gordon Chung connect with you to help
18:27:18 <henrynash> heckj: ok, sign us up
18:27:19 <gyee> thanks!
18:27:53 <heckj> #topic open conversation
18:28:01 <topol> (and Steve) :-)
18:28:02 <heckj> er, unless you've more there Henry?
18:28:14 <henrynash> heckj: nope, that's it
18:28:47 <henrynash> so one, thing for open discussion: we need to pull in the oslo policy engine
18:29:46 <henrynash> …and then really take a close look at what a v3 policy.json file will likely look at and makes sure er think a customer could control the api in a sensible fashion
18:30:54 <henrynash> I'll take that if nobody else wants to :-)
18:30:55 <heckj> henrynash: yeah, makes sense
18:31:43 <dwchadwick> there is a standard json api for a policy engine recently been released by the XACML group
18:31:49 <dwchadwick> we should consider using this
18:32:24 <dwchadwick> If this is going to become the standard api for policy engines then we would be silly to reinvent our own
18:32:39 <henrynash> dwchadwick: sounds like the route to that would be for the oslo team to consider it and then we would pick it up if it gets endoresed
18:32:40 <dwchadwick> we already use the XACML XML api for our policy engine
18:33:07 <dwchadwick> We are going to migrate our policy engine to this api anyway
18:33:49 <dwchadwick> I guess I should get in touch with the oslo team. How do I contact them
18:33:59 <henrynash> heckj: ?
18:34:07 <heckj> dwchadwick: how different are the implementations and semantics of the policy engines? If there's a huge mismatch, we're looking at a lot of work to make it fit on top of the effort of changing across all of openstack
18:35:07 <heckj> oslo team lead is effectively markmc (Mark McLoughlin - probably just mangled his name) - would ask on #openstack-dev for him (he's in dchadwick's timezones) or scan through the mailing list
18:37:40 <dwchadwick> I will do this, thanks
18:37:41 <heckj> henrynash: how familiar are you with devstack?
18:37:48 <henrynash> heckj: fyi, we have a discussion going on regarding whether we can feed filter attributes into the policy engine
18:37:53 <heckj> dwchadwick: sounds good - looking forward to hearing the latest
18:38:05 <topol> heckj: I know a little devstack
18:38:06 <henrynash> heckj: oops, sorry crossed questions
18:38:16 <heckj> no worries
18:38:26 <henrynash> heckj: tool probably knows more than me :-)
18:39:01 <topol> henrynash, in US english calling someone a tool is an insult :-)
18:40:10 <dwchadwick> he took the p out of you ;-)
18:40:27 <topol> He must know me :-)
18:40:33 <henrynash> heckj: idea is that if someone does, e.g. GET /users?{domain_id="my domain"}  can we ensure the policy engine will let us protect this call by whether I have a domain scoped token to "my domain"
18:40:47 <henrynash> topol: oops, sorry, good thing I do know you :-)
18:42:26 <henrynash> the sound of silence…..
18:42:37 <heckj> sorry - in two meetings at once - back in a sec
18:42:42 <topol> :-)
18:42:47 <dwchadwick> the whole issue of access control to the policy engine is an interesting one, because you could easily introduce recursions (policy controling access to policy engine ;-)
18:44:53 <dwchadwick> Out of interest, who is allowed to call the policy engine
18:45:25 <heckj> jumping back up the stack in my head - I think it's clear we want to be able to feed in additionla additbutes into the policy engine to let it work against that additional set of data
18:45:57 <henrynash> dwchadwick: so each service calls the policy engine with a) the details of the request and b) details extracted from the token provided by the caller
18:46:04 <heckj> dwchadwick: the policy engine is called by each of the services - they "own" their  authroization, and use the common library to enable it
18:46:26 <dwchadwick> but what is to stop me using a client to call the same API?
18:46:41 <henrynash> dwchawick: it is not exposed
18:47:00 <dwchadwick> but it exists at some URL.
18:47:11 <henrynash> errr, don;t think so
18:47:29 <dwchadwick> so its not a RESTful API
18:47:43 <dwchadwick> The XACML json api is restful I believe
18:47:48 <henrynash> (correct me anyone if I have this wrong_ but its a private call internal to each serbice
18:47:52 <henrynash> service
18:48:17 <heckj> it's not a restful API, it's a python API internal to the services
18:48:38 <henrynash> dwchadwick:….and not everyone has the same version of the policy engine….yet
18:49:01 <dwchadwick> Ok understood. Then perhaps the oslo team wont be so keen on the XACML approach
18:49:17 <henrynash> dwchadwick: I would not assume that
18:49:41 <heckj> pretty much everything the oslo team is doing it python libraries in use by multiple services, but I don't think anything's really off the table
18:49:46 <henrynash> policy engine as  a new OS service?
18:50:03 <dwchadwick> what we have done is SSL enabled the link to the policy API so that only trusted clients can call it
18:50:39 <henrynash> (hmmm…but it needs to be fast as it is called inline as part of every call)
18:51:05 <dwchadwick> I know. Ours is not fast, not when you do SOAP and XML and SSL
18:51:27 <dwchadwick> We have a programmable API as well that is fast
18:51:43 <dwchadwick> this is more equivalent to the python call
18:51:54 <henrynash> dwchadwick: probably...
18:52:17 <henrynash> any other issues…don't want to hog the floor
18:52:43 <henrynash> (probably a UK expression, that)
18:52:57 <dwchadwick> Just to let you know that Kristy has almost finished implementing the federated keystone blueprint of Adam
18:53:21 <dwchadwick> But using our federation infrastructure instead of his kerberos like mechanism
18:53:27 <gyee> henrynash, have you give some thought into how to migrate the swift ACLs with <tenant name>:<username>?
18:53:45 <gyee> or *:<username>?
18:54:35 <henrynash> gyee: so an initial review is that we might get away with it for now…..but still trying to get this confirmed..gyee/heckj: who would be the best person in swift to chat to?
18:55:27 <gyee> I implemented the cross-tenant ACLs :)
18:55:30 <heckj> henrynash: really good question
18:55:37 <gyee> the latest ones anyway
18:56:06 <heckj> henrynash: I'd suggest starting with chmouel - he has excellent cross knowledge there, but also worth just hopping to the top (jon dickinson)
18:56:28 <notmyname> s/jon/john/  ;-)
18:56:37 <heckj> sorry notmyname
18:56:47 <henrynash> heckj: thx
18:57:05 <dwchadwick> Just located markmc@redhat.com  is this the Mark of oslo
18:57:12 <heckj> that's him
18:57:24 <gyee> henrynash, I am think to have authtoken middleware set the X-Domain-* headers if the domain is not the default domain
18:57:35 <notmyname> at the last swift meeting, chmouel said he would be able to look in to the swift+keystone v3 and migration issues.
18:58:05 <henrynash> notmyname: great….either gyee or I can provide guidance
18:58:22 <gyee> and have Swift authorized on project@domain:username@domain if X-Domain-* is present
18:58:37 <henrynash> gyee: not sure if we set X-Domain if it is a project token….
18:58:37 <gyee> otherwise, do it the old fashion way
18:58:58 <gyee> we should
19:00:08 <heckj> time to wrap this up
19:00:11 <heckj> #endmeeting