18:00:51 <heckj> #startmeeting
18:00:52 <openstack> Meeting started Tue Jul 31 18:00:51 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:04 <heckj> Okay - let's get this ball rolling
18:01:41 <ayoung> http://wiki.openstack.org/Meetings/KeystoneMeeting
18:01:56 <ayoung> #topic domains
18:02:02 <heckj> ayoung was gracious enough to get us an agenda set up
18:02:26 * ayoung has to leave at about 1:45..so in a bit of a hurry
18:02:28 <heckj> ayoung: what's the domain topic?
18:02:30 <heckj> np
18:02:50 <ayoung> heckj, OK,  so Domains is gyee's bailywick.  I figured we should sort out what we are doing with them
18:03:06 <ayoung> My take is:  get them in in a minimal format
18:03:09 <ayoung> no groups
18:03:22 <ayoung> and first we need an agreement of what is acceptable/expected
18:03:29 <heckj> ayound: adding as extension to V2 API, or dependent on V3 API?
18:03:41 <gyee> not sure if anyone have a chance to look at my draft review
18:03:56 <ayoung> gyee, have you changed it recently?
18:04:00 <gyee> no
18:04:02 <heckj> I've glanced over it, but not read in depth
18:04:08 <gyee> why change it, its perfect :)
18:04:39 <ayoung> #link http://etherpad.openstack.org/keystone-domains
18:05:11 <ayoung> gyee, since we are not doing a formal V3 for Folsom anyway, are you OK with doing it as an extension?
18:05:14 <heckj> adding domains as an extension to V2 API isn't an issue, but changing the token format and output would be a significant API change - which I believe is needed to make it useful to external services
18:05:19 <ayoung> We can migrate Extension to V3 in Grizzly
18:05:30 <gyee> sure
18:05:38 <gyee> as of know, the code is parked in contrib
18:05:40 <gyee> now
18:05:43 <ayoung> good
18:06:02 <gyee> so are we OK with the current impl?
18:06:09 <ayoung> OIK,  so my understanding is that each user and tenant is owned by exactly one domain
18:06:13 <gyee> I heard rejection city the last go around
18:06:35 <ayoung> gyee, I heard arguing over details,  but I think that we were close to consensus
18:07:04 <liemmn> FYI...  Guang's implementation would support the single-home user RBAC model, i.e., a user may have only one home domain.
18:07:15 <liemmn> http://etherpad.openstack.org/KeystoneRoles
18:07:33 <gyee> right
18:07:39 <heckj> It's unclear that users need to be fully segmented as well - using the policy engine, we can get the same enforcement
18:08:15 <ayoung> heckj, I see this as more "the eggs Policy usese to make omlettes"
18:08:20 <gyee> if we have the domain_id in the users, we can easily implement isolation
18:08:27 <ayoung> you have to put a user "somewhere"
18:08:34 <heckj> and with the V2 API, the "admin" has uber-rights over everything
18:08:34 <ayoung> once we put them there, they stay there
18:08:55 <gyee> heckj, with my impl, domain admin can control their own domain
18:09:07 <gyee> domain admin is a role
18:09:29 <heckj> Yep - not asserting what your code does, asserting what current code and V2 API expectations are
18:09:33 <gyee> meaning user from one domain can have the domain admin role in multiple domains
18:10:30 <gyee> we are not doing anything outside the realm of RBAC
18:10:55 <ayoung> heckj, is the question "a mechanism that is  domain specific" versus  "a mechanism based on the policy impl?"
18:11:15 <ayoung> IE,  we can implement the domain spec using the policy code?
18:12:24 <heckj> (in V3) I think we have everything we need to enforce the domain admin needs even down to users using policy
18:12:44 <heckj> My primary concern with gyee's current extension/V2 work is that I don't think we can meaningfully make this a V2 API extension
18:12:55 <heckj> If we start changing responses to the API, we'll get a lot
18:13:05 <heckj> of pushback that the API needs to be revised/revisioned
18:13:18 <heckj> (recent conversations related to changing the API and what that means to versioning)
18:13:20 <ayoung> heckj, agreed that we are too late to do modifications of V2 APIs
18:13:29 <liemmn> I think that domain is a core concept and should be part of the core, rather than an extension...  It is messier as an extension.
18:13:39 <ayoung> liemmn, yes,  but not until V3
18:13:43 <liemmn> yep
18:13:47 <heckj> liemmn: I'm totally with you - and I think it needs to flow all the way out ot all services (nova, glance, etc)
18:13:50 <liemmn> hence, voting for v3
18:13:58 <liemmn> (as core)
18:14:13 <heckj> I really appreciate gyee's work, but I think we'd be better getting identity wrapper and moved in a V3 API and get started with impl there
18:14:34 <gyee> I am OK with V3
18:14:39 <gyee> but we have to have user isolation
18:14:56 <gyee> which means domain_id in users
18:15:17 <ayoung> gyee, so long as it is an attribute, and not in the URL that should not break anything
18:15:36 <ayoung> I think that meets the letter of the law WRT  dkranz's policy doc
18:15:37 <gyee> right
18:15:53 <gyee> domain_id is an attribute of user, just like tenant
18:16:39 <ayoung> gyee, so do you have enough to get a new impl out for review?
18:16:47 <gyee> keep in mind that having domain_id in user does not prevent user from *assigning* to tenants
18:16:57 <heckj> gyee: I'm asserting that you can and do have domain isoliation of users with a reasonable use of policy.json. I don't think it's critical to enforce it in the data model as well
18:17:09 <liemmn> With domain model + domain_id on user, I think we can implement the user isolation as described in the KeystoneRoles doc ("single-home user" option)
18:17:23 <gyee> ^^^ what he said
18:17:23 <uvirtbot> gyee: Error: "^^" is not a valid command.
18:18:10 <ayoung> heckj, so to add a new domain, we would need to update policy.json ?
18:18:20 <gyee> I am ready to rock n roll if you guys are cool with it
18:19:16 <heckj> ayoung: not at all - just add a role & rule in policy.json that to add a user, reset a user, etc you need to be the domain admin for relevant tenants
18:19:40 <ayoung> heckj, I think that domain_id would be default to null for most deployments, but be in the data model to be used in "multi domain deployments"
18:20:07 <heckj> If the implementation you have completey segregates tenants and users are in tenants, you can use the default_tenant_id to determine the appropriate domain to use to verify for password resets and such
18:20:58 <ayoung> heckj, but tenants can't be nested, and thus we don't have an organizational mechanism for tenants/
18:21:02 <heckj> ayoung: if it's null, then it can't be mandatory. If it's optional, then what's the difference between it and using the domain assocaited with the default tenant?
18:21:24 <heckj> ayoung: in this first cut, they can't be nested - but I think we all agree that we want to enable that in a future round
18:21:25 <gyee> heckj, have default_tenant_id as domain_id, we are essentially overloading the meaning of default tenant
18:21:28 <gyee> not very flexible
18:21:51 <gyee> and confusing
18:21:55 <liemmn> heckj, I provided an argument against using default tenant for linking domain in the KeystoneRoles document.
18:21:56 <heckj> gyee: I absolutely do not want to overload a value
18:22:07 <jlr> default tenant is for scoping the token.  domainId is for isolating the user
18:22:09 <gyee> amen
18:22:12 <heckj> I'm happy using them as a chain to look up relevant data, but the meaning of an attribute has to be crisp and clear
18:22:40 <gyee> so what's the problem with having domain_id and default_tenant_id as separate attributes?
18:22:43 <gyee> that's very clear
18:23:09 <liemmn> I think that is overloading the usage of default tenancy.  If I understand correctly, default tenancy is used for the purpose of authentication if a tenant is not specified.  A default tenant is also optional.  A user's "home domain" is not.  A user (except for a super-admin) must always have a "home domain."  So, I decided to introduce the concept of "home domain" for better separation of concern and enforcement of immutability.  To
18:23:09 <liemmn> answer your question:
18:23:09 <liemmn> 1) "can a user have a default tenant but a null home domain?" -> No, a user (except the super-admin) always has a home domain.
18:23:10 <liemmn> 2) "can a user's default tenant not belong to the user's in the user's home domain?" -> Yes, in the given proposal, user's default tenancy and home domain are 2 separate concerns.  For example, I have a guest tenancy in domain B and a home domain A.  However, whenever I log on, I always want to log onto the guest tenancy I have in domain B.  Therefore, I will set my default tenancy to guest tenancy in domain B.
18:23:17 <heckj> gyee: that is clear - are you OK with asserting that domain_id is optional and can be null?
18:23:17 <liemmn> (cut-and-paste)
18:23:31 <gyee> I am OK with it being "null"
18:23:44 <heckj> gyee: and thereby being also optional?
18:23:47 <gyee> deployment does not use domain doesn't need to set a domain_id
18:23:54 <ayoung> heckj, I would state that for all domain_id = null we assume the default domain.
18:24:05 <ayoung> As opposed to any chained lookup
18:24:15 <gyee> sounds good
18:24:19 <jlr> it is an all or nothing thing... if it is used in a deployment, it is a mandatory field
18:24:21 <liemmn> Maybe we can create a configuration to specify if the deployment is a "domain-aware" deployment (similar to PKI, for example)... If it is so, we will need to enforce non-null domainId when creating a user.
18:24:33 <jlr> +1
18:24:38 <gyee> +1
18:24:39 <heckj> ayoung: inconsistency is going to bite us there
18:24:58 <liemmn> It's a deployment option.
18:25:08 <gyee> I am OK with that
18:25:15 <heckj> liemmn: and you're arguing to encode deployment options in the data model, which I'm not OK with
18:25:19 <ayoung> heckj, you mean there is the potential for an inconsistnacy between the domain of the user (null) and the domain of the default tenant?
18:25:24 <liemmn> data model is always there.
18:25:27 <heckj> ayoung: yes
18:25:45 <ayoung> heckj, I would say that is an acceptable setup in some cases
18:25:51 <liemmn> enforcement of non-null domainId is there... For a domain-aware install, a user without a domain does not make sense.
18:25:54 <ayoung> say a migration scenario
18:26:01 <heckj> I'm ok with adding a domain_id attribute to the user *if* we assert it can be Null, and therefore is an optional attribute based on backend driver
18:26:02 <ayoung> where a domain was not used in the past
18:26:14 <gyee> hackj, +1
18:26:22 <gyee> heckj, my bad
18:26:23 <ayoung> heckj, I can buy that
18:26:28 <heckj> no
18:26:29 <heckj> np
18:26:33 <heckj> now I can't type
18:26:39 <gyee> :)
18:26:53 <liemmn> gyee spreaded the can't type bug
18:27:07 <ayoung> OK.  gyee can you write up what we agreed on here in a couple short sentances and we';; # action them?
18:27:09 <gyee> its my middle finger
18:27:30 <gyee> ayoung, you got it
18:28:30 <ayoung> heckj, OK to move on to PKI?
18:28:45 <liemmn> ayoung, for migration from a non-domain deployment to a domain-aware one, we will need to lob all those users into some sort of default domain...
18:28:52 <ayoung> liemmn, exactly
18:29:24 <heckj> liemmn: +1
18:29:26 <ayoung> so there might be a point where a default tenant is part of a domain, but the user isn't or some other weirdness
18:29:27 <heckj> ayoung: yep
18:29:30 <heckj> #topic PKI
18:29:45 <ayoung> first up is location of the cached certs
18:29:58 <ayoung> it came to my attention that sticking them in /tmp is a no-no
18:30:29 <ayoung> there is a potential elevation of privs:  say a user on the Keystone system gets to /tmp/keystone-blah  ahead of time
18:30:34 <ayoung> and sticks in their own cert
18:30:48 <ayoung> then they can authenticate using a bogus token
18:31:09 <ayoung> So the question is what should the default be?
18:31:16 <heckj> ayoung: any way we can make that a configurable option?
18:31:23 <ayoung> heckj, it is already
18:31:36 <heckj> ayoung: ah, we're just talking about sensible default then
18:31:37 <ayoung> the question is what should the default be,
18:31:43 <ayoung> yep
18:31:48 <heckj> proposal: /var/lib/keystone
18:31:50 <heckj> ?
18:31:58 <ayoung> I think /var/cache is slightly more correct
18:32:05 <ayoung> but then the issue is the user name
18:32:06 <ayoung> so
18:32:23 <gyee> what's the issue with user name?
18:32:26 <ayoung> /var/cache/<server>/keystone-certs
18:32:31 <ayoung> gyee, OK  possible race condition
18:32:44 <ayoung> assume that there are two services running as the same user,  say nova
18:32:51 <ayoung> and both get a request at the same time
18:33:03 <ayoung> one fetches the certs, and starts writing
18:33:17 <ayoung> the other tests for existence of the files, which succeeds, and attempts to validate
18:33:28 <heckj> ayoung: I'm ok with /var/cache - sounds like you've got to deal with the async race regardless of directory
18:33:28 <ayoung> validation will fail since they only have say, half a cert
18:33:55 <ayoung> heckj, so, will /var/cache be acceptable across the distros?
18:34:04 <ayoung> There is nothing in there right now
18:34:33 <heckj> ayoung: as far as I know, yeah - I'd poke a quick question at adamg or zul in #openstack-packaging if you want an ubuntu check
18:34:38 <ayoung> we'll have to modify any install process to make a writable subdir in there
18:35:01 <ayoung> and I am not sure the correct general mechanism to do that
18:35:13 <ayoung> so lets take that as a #action?
18:35:28 <liemmn> ayoung, you can use a touch file to specify that a cert has been written completely.
18:35:39 <ayoung> liemmn, yep
18:35:46 <heckj> ayoung: sounds reasonable
18:36:33 <ayoung> liemmn, maybe even the cert fingerprint....
18:36:43 <gyee> +1
18:36:54 <gyee> we use fingerprint for out-of-band validation as well
18:37:07 <ayoung> #action use the cert fingerprint as a touch file to indicate download has completed
18:37:13 <liemmn> yep
18:37:16 <ayoung> heckj, can I get ops to post?
18:37:37 <heckj> ayoung: I'm being dense. "ops to post"?
18:37:45 <ayoung> or, better yet,  you repost my #actions,  that way I get spellcheck :)
18:37:51 <heckj> Ah!
18:38:03 <heckj> #action ayoung to
18:38:09 <heckj> #action ayoung to use the cert fingerprint as a touch file to indicate download has completed
18:38:11 <heckj> heh
18:38:16 <heckj> you're going to hate this
18:38:53 <ayoung> #action check with adamg or zul in #openstack-packaging about use of /var/cache for certificates
18:39:00 <heckj> #action: ayoung to touch base with Zul/AdamG (or IRC #openstack-packaging or mailing list in general) to check on suitability of /var/cache/**/ directory creation on install
18:39:13 <ayoung> heckj, you are wrong.  I love this
18:39:23 <heckj> heh
18:39:31 <heckj> more on PKI?
18:39:42 <ayoung> OK...let me come back to acceptance criteria...
18:39:46 <ayoung> two quick matters
18:39:55 <heckj> #action: add domain_id as optional attribute to V3 API model on users
18:40:26 <ayoung> one,  I've been told that the enable/disable for pki config options are poorly named
18:40:35 <ayoung> they don't like my double negatives
18:40:49 <ayoung> so I am thinking:  token_format = PKI | uuid
18:41:04 <gyee> heckj, is the /v3 path implemented, where am I going to park the domain code?
18:41:22 <ayoung> with uuid being the equivalent of the current default
18:41:44 <ayoung> gyee, do you mean in the future?
18:41:50 <gyee> near future
18:41:56 <ayoung> I would assume it would have to be part of the identity provider
18:42:43 <heckj> gyee: It's be under the identity provider for a V3 api route
18:42:52 <gyee> oh ok
18:43:04 <ayoung> OK, I have to disappear
18:43:40 <heckj> ayoung: ciao
18:43:59 <ayoung> I'll start an etherpad for Summit sessions.
18:44:16 <ayoung> We can argue there and get it down to areasonable number
18:44:44 <ayoung> unless there is a better suggestion?
18:45:30 <ayoung> OK...I'm gone.  I'll beat you guys up over the rest of the Agenda items in #openstack-dev
18:46:08 <heckj> kk
18:46:18 <heckj> Other topics/issues?
18:48:03 <gyee> v3 api
18:48:06 <gyee> (DELETE) /users/{user_id}/roles/{role_id} ==> delete_role_from_user
18:48:31 <gyee> if I assign the same role to multiple tenants, which role is the above deleting?
18:48:54 <gyee> all of them?
18:49:31 <liemmn> unless the tenantId is part of the payload somewhere
18:49:48 <liemmn> but, that's not very restful
18:49:48 <gyee> right, same for domain roles as well
18:50:16 <heckj> gyee: good question
18:50:35 <liemmn> Also... we need an update API for credentials (my feedback on draft#3)
18:51:08 <liemmn> so, to allow update to an access key, for example (enable/disable)
18:52:18 <gyee> speaking of access key, we are ready to start on the tempURL impl
18:53:22 <liemmn> I've got to run... Later, heckj
18:53:36 <heckj> gyee: I believe so
18:53:53 <heckj> liemmn: I'll hit a draft update this week/weekend if nothing else
18:54:13 <gyee> then how do we remove just a tenant-role association?
18:54:26 <gyee> or domain-role association
18:55:47 <heckj> gyee: we should totally be able to do that - I need to re-read that section to see what the hell I was thinking
18:56:14 <gyee> oh ok :)
18:56:26 <heckj> yeah - very distracted right now
18:56:42 <heckj> Im going to wrap this up
18:56:45 <heckj> #endmeeting