18:00:48 #startmeeting keystone 18:00:48 Meeting started Tue Feb 5 18:00:48 2013 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:48 yay! 18:00:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:51 and is! 18:00:52 The meeting name has been set to 'keystone' 18:00:57 Whassup dolph? 18:01:14 heckj: not much, belatd welcome back 18:01:16 belated* 18:01:27 heh - closer to surface now - it's not dark anymore :-) 18:01:29 bleated? 18:01:41 dolphm: missed out on last week's keystone meeting 18:02:09 #link http://wiki.openstack.org/Meetings/KeystoneMeeting 18:02:15 Okay - looking over the agenda 18:02:31 I see we haven;t updated since last week 18:02:40 BTW: I've got to keep things short on my side today - will get heavily distracted in about 30 minutes as I'm trying to run two meetings at once 18:03:17 #topic Hot, Burning Issues of Love? 18:03:21 I have friends who play online poker and play 10 tables simultaneously. You can handle 2 meetings 18:03:41 topol, they play with their money, not with mine 18:03:52 anything in the frying pan this week? 18:03:58 critical reviews pending, etc? 18:04:08 gyee's work on V3 Token is probably most critical 18:04:13 heckj: so we need the auth review done 18:04:20 ayoung: +1 18:04:20 you guys OK with the spec now? 18:04:37 gyee: you saw my comment on the unstopped token bit….. 18:04:51 henrynash, can you link 18:05:24 henrynash, I am still uncomfortable with the concept of private namespace 18:05:35 +1 gyee 18:05:40 still get wrap my head around on how does it work in conjunction with public namespaces? 18:05:45 dolphm: I think most of the holdout last week was related to commentary related to multifactor and token structures, which I think mostly got resolved with a general agreement to leave it open and assert extra keys should be ignored. This jive with you? 18:05:47 still can't 18:05:52 https://review.openstack.org/#/c/20524/15/openstack-identity-api/src/markdown/identity-api-v3.md 18:05:56 seeing the impact of private namespaces on openstackclient makes me sad 18:06:03 heckj, it jives with me 18:06:16 dolphm: ? 18:06:24 me too 18:06:28 I think we need more impact on the private namespace 18:06:33 impact study 18:06:51 can private namespaces be implemented later, or do they need to be designed in up front> 18:06:52 ? 18:06:52 I still think we either going to have namspace for all or nothing 18:07:03 gyee: I guess my concerns is we had this debate, approved the blueprint 18:07:05 heckj: sure 18:07:34 I am OK with namespace, just not *private* namespace 18:07:50 tbh, when i +2'd the spec, i didn't expect it to merge so fast -- i was just happy with the way it was written... i probably should have +1'd 18:07:53 gyee: there is very little code change that that would cause…..but of course it would be a hard on/off 18:08:06 if it's a feature we can't fully deliver in the next 10 days, we need to cut it from the spec, and put it back for v3.1 18:08:14 gyee or henrynash: can one of you summarize how namespace is impacting the spec and the choice that needs to be made there? 18:08:20 dolphm:: we can definitely deliver it 18:08:43 heckj: There are two spec changes: 18:09:08 I am half way there with the auth impl 18:09:13 1) Specifiy domain in auth when usernaem is specified 18:09:24 tooks 2 days, at this way, I should have a wip review in the next 2 days :) 18:09:33 discussion on impact to openstackclient: https://review.openstack.org/#/c/20854/4/openstackclient/identity/v3/credential.py 18:10:11 …as well as domain alongside for project scope/default to ensure these are unique….all in auth or scoping 18:11:40 dolphm: do you think there is an issue there in terms of adding the filtering? 18:11:55 the idea that we have to retrieve the user's domain in order to figure out the namespace is not very performance friendly 18:12:09 henrynash: adding ?domain_id= to GET /users and GET /projects? 18:12:20 dolphm: yes 18:12:25 henrynash: not at all 18:13:03 gyee: sure. but we do this how often? 18:14:07 henrynash, can you update the doc on how does private domain work in conjunction with public domain? 18:14:26 gyee: you mean 'default' domain? 18:14:54 not just default 18:15:32 gyee: not quite with you….what do you mean by public domain? Any domain, not private? 18:15:34 say I have user jdoe in default/public domain, and I want to create a user jdoe in a private domain XYZ 18:15:41 so, private domain = private namespace, allows usernames to be unique for that domain instead system wide. If not used, then users get a default (public) domain and domain isn't required for authN? 18:15:42 how does that work? 18:16:04 joesavak: yes 18:16:04 and how does it impact other OS services? 18:16:32 i like the flexibility 18:16:57 gyee: dashboard is the (only?) impact i'm aware of -- users in a privately namespaced domain can't login 18:17:08 gyee: so the only real potential is swift, and looking at the with auth code, there might actually be no changes (still being checked - if there are they are minor) 18:17:19 swift containers seem fine 18:17:50 swift ACL has legacy code that checks tenantID as well as useranme, so that *might* can no changes…. 18:17:54 dashboard will need to do something like .horizon.com and send in domain id with the user/pass for authN if configured in the OS deployment 18:18:07 joesavak: yes 18:18:15 can anyone give the rationale for why user names and project names can be locally defined in a domain but role names cannot be. Seems illogical to me 18:19:05 dwchadwick: it is a artefact that today the role names are shared identifiers between all services and keystone 18:19:06 dwchadwick: we need to have domain-specific policy first 18:19:10 dwchadwick, as of now, policy is specificied at a service level, so private roles would be meaningless 18:20:10 we need policies tied to explicit capabilities to enable private roles. 18:20:48 but if you have service wide policy, how can that work with domain specific user names and not with domain specific role names 18:21:01 gyee: reading through this, there's some impact on other services for a private domain concept with V3 auth impl (not suprising), and the argument against so far that I've caught is that it's not performant, and we'll need to be clear about expectations for interop when using and not using domains. Does that summarize your concerns? 18:21:05 gyee: I understand the desire to have a hard switch on namespace….but since there wold be very little code change that this saves, I think the flexibility we get from the current spec, outweighs any gain 18:21:21 dwchadwick: policy files have no concern for user names 18:21:42 heckj, that sounds right 18:21:47 dwchadwick: let's keep this to one topic at a time please - fine to bring that up later, but let's sort out the current spec disagreement 18:21:53 policy does not care about user names. Policy as it is currently makes decisions based on roles and tenants. 18:22:18 heck, gyee: I'm not sure about the performant bit…this is for auth when we need to do the look up, not each token check? 18:22:19 later when we give it a full go on namespace, then what's the advantage of private domain? 18:22:22 henrynash: it's the client-side code impact that seems much larger 18:22:32 but tenants (now projects) can be domain specific 18:23:01 can someone please define (or link to a definition of) a private namespace? 18:23:34 problem with private domain, is that from now on, given a name, I have to do a looking on the domain 18:23:44 lookup 18:23:50 joesavak relayed this earlier, which I thought covered it: so, private domain = private namespace, allows usernames to be unique for that domain instead system wide. If not used, then users get a default (public) domain and domain isn't required for authN? 18:23:50 ayoung: so the spec is probably the best: https://review.openstack.org/#/c/18805/ 18:23:56 ayoung: you approved the review lol 18:23:59 unless the domain name is always provided, or in its absence you can assume default 18:24:13 then all names can be local to the domain 18:24:29 heckj: yep, it's really that simple": names are private to that domain or they are not 18:24:48 dolphm, yeah, but I think that it might mean differently from I origianlly interpreted it 18:24:52 its not just default domain 18:25:08 say if I have 3 public domains and 1 private domain 18:25:27 #link https://docs.google.com/document/d/1c6Tvr_zRMOP2mJCQN9lrfJjxGaXAExXiFlwMDvmXbl4/edit 18:25:29 name is globally unique across all the public domains 18:25:38 gyee: so today, names are global across all domains 18:25:39 this is confusing just to describe it 18:26:05 i'm lost on how the default domain has any impact on public/private namespacing? 18:26:23 Its not confusing if you get a nice description written up somewhere 18:26:43 dolphm, for a given name, I don't know if its globally unique till I lookup its domain 18:26:44 gyee: that stays true expect for and names that are in a domain that was created with the "private" flag set….in which cases those names are in their own private name sapce 18:26:47 think of public domain as a single default domain (only one can exist) and it is basically the absence of a private domain 18:26:48 gyee: well, that's how it is today! 18:27:09 OK...so a "private" namespace is a namespace. THe private does not imply privacy concerns, but rather a way to divide uniqueness between two realms, so usernames and tenant names can be reused, correct? 18:27:12 1) user names share a single namespace across all publicly namespaced domains, 2) project names share a single namespace across all publicly namespaced domains, 3) user names have their own namespace within a privately namespaced domain, 4) project names have their own namespace within a privately namespaced domain 18:27:19 henrynash, gyee: I'm missing the distinction between public and private domains - hven't seen an identifier to assert which it is. I've been under the impression that if there *is* a domain at all, it's a "private" domain in the curren conversation. Is there a disinction there I'm missing 18:27:43 ayoung: yes 18:28:15 when you create a domain there is a public/private flag 18:28:26 ayoung: meaning that a username or project name without a domain for context *may* be ambiguous, but you're forced to check for it in the public namespace because you don't know which private namespace to look in 18:28:28 dwchadwick: ah, thank you - missed that. 18:28:29 heckj: on domain create, you can specify pivate_user_names and/or private_project _names true/false 18:28:49 heckj: default is false - i.e the current situation 18:29:05 and you should also be able to specify public/private role names as well ;-) 18:29:22 dwchadwick: another battle, not this one :-) 18:29:41 Can't we simply make names scoped to domain? 18:29:44 heh, just can't keep a good academic down, can you 18:29:47 dwchadwick: i agree 18:30:14 its all part of the same battle. Having a clean model that is consistent and understandable rather than adhoc 18:30:25 what battle? :) 18:30:37 see how confusing this thing is? 18:30:45 the battle over the v3 API ;-) 18:30:46 dwchadwick: unfortunately we don't start with a blank slate for every release 18:31:14 we either going to have namspace or we don't, much easier to understand 18:31:14 haneef - i think the way henrynash did it allows for an easier transition from v2 to v3. As discussed earlier there are ripple effects when domainId is required for authN in addition to user/pass. If v3 impl provided an easy way to transition from user-unique across all domains to user-unique to a domain it will help adoption 18:31:21 henrynash, gyee - frankly, the distinction seems needlessly complex and simply a means of enabling a break in the uniqeness rules that we currently are living under. I think (maybe this is what gyee was arguing) that we would be better making usernames specific/unique to domains from the very start - revising what we're doing today 18:31:24 but adding more spaghetti to the plate makes it more difficult to untangle in the long run 18:31:38 heckj, amen brother! 18:32:09 I am NOT against namespace, I am against *private* namespace 18:32:15 so as a compromise here, let me suggest the following: 18:32:32 gyee - what is the difference? 18:32:41 we change our asserting that user names need to be globally unique, and instead only enforce uniqueness to a domain 18:32:50 we remove the concept of public vs. priviate domains altogether 18:32:52 all namespaces are private until make global 18:33:02 dwchadwick, yes 18:33:08 heckj , totally agree. Don't need to write so many pages in document to explain private/public domain in docs. Simply make it domain scope 18:33:12 I agree "all namespaces are private until make global" 18:33:20 but...you should be able to run that backwards 18:33:25 we make additional implementation notes in the spec asserting that there is a concept of a default domain, and if a domain isn't specified in auth, that auth is assume to go against the default domain 18:33:31 ayoung: "backwards"? 18:33:49 it should be possible to split a global namespace into multiple private ones down the road 18:33:58 if the pool is globally unique to start 18:34:05 heckj: you can't make a private namespace public -- there will be collisions with the existing public namespace 18:34:07 default domain will help v3 adoption 18:34:12 you should be able to split that into multiple pools of names where the names start to overlap 18:34:42 there should be a default domain. THat is the domain for all users. THe problem is on how to split it up after wards 18:34:50 if you l;ook at the DNS syustem, they are split on dots 18:35:04 ldap splits on the whole cn=, comma 18:35:38 and so if some people are doing username with email addresses, and you start splitting on domain name, now people that were in the same domain are split into different 18:36:12 ayoung@redhat.com would be partitioned into a different domain than admiyo@yahoo.com, even though they are both MY email addresses. This is the process we need to keep in mind 18:36:13 heckj: so I am am absolutely fine with this approach…and indeed I started there! The thing we are really saying is that the use of domains will really be for enterprises that want to have their own namespace and won't accept restrictions of clashing with others 18:36:19 So...we start with Folsom 18:36:26 the concept is simple. You take your own private name and prefix or suffix with your name (i.e. name of parent) to turn it into a global name 18:36:33 and the V2 API. And we specify how things will grow into the V3 API 18:36:35 to support v2, can't we create a predefined v2 domain and move all the users to it. 18:36:52 Haneef, +1 18:36:54 we have the v2 thing coverered 18:36:58 heckj, I am fine with your proposal 18:37:04 have namespace applicable to all 18:37:17 Lets call it DOM0 just to confuse the Xen guys! 18:37:25 Haneef: we already did that 18:37:30 when you upgrade from F->G, all users and projects end up in the default domain and v2 and v3 clients will find them fine 18:37:40 sweet 18:38:14 So we don't even need to worry about default domain, for v2 users, it is v2 domain, and v3 , they are going to create a new domain or use existing one 18:38:33 dwchadwick, "the concept is simple. You take your own private name and prefix or suffix with your name (i.e. name of parent) to turn it into a global name" that leads to things liike Kerberos tickets: ayoung@example.com@EXAMPLE.COM 18:38:50 BNotice the double @ incase I didn't make it clear enough 18:39:23 with current proposal - user in private namespace will never be able to access diferent domains/project meanwhile user in global name space can get this acces and that could be problem in just private namespaces (possible name-clash) - right? 18:39:24 ayoung, that looks like my email@EMAIL 18:39:32 yes exactly. As the world grows and domains merge then you need to add another level to the name 18:39:32 haneef: better than that, domain is optional in v3, so if the cloud provider want to run in "folsom" mode, the just never specify a domain on any entity and it all ends up in one big default domain with folsom semantcis 18:39:51 Since we have not ruled out any characters in usernames, we can't specify a means to concatinate username and domain in a singled string. 18:40:24 ayoung, email is unique across the world 18:40:26 I suggested you make it a config parameter that each OpenStack installation can decide 18:40:30 henrynash, so, is there fundamentally and difference between saying "we have multiple domains" and "we have multiple namespaces?" 18:40:41 In this way you cater for Chinese, Korean, Japanese etc 18:41:01 ayoung: +1 to straight up concatenation is impossible 18:41:10 gyee, yes, but we are not currently splitting domains on email addresses. If we do that,. we end up with one domain per unique email address in the system....sub optimal 18:41:22 ayoung: if we take the approach suggest here, then no every domain is its own namespace 18:41:39 henrynash, and I think that is the right approach 18:42:07 so lets drop the term "private" from discussing namespaces. What we should say is something like this: 18:42:16 1. IN folsom, there is one domain and one namespace 18:42:34 2 Grizzly there will, by default, also be one domain and one namespace 18:42:44 3. If you want to enable an additional domain, you can do so 18:43:01 4. this domain will have a separate namespace from the existing domain. 18:43:10 ayoung: +1 18:43:11 4. But you have to specify the domain name always 18:43:15 I think this maps to how people will want to use it. 18:43:20 ayoung +1 18:43:28 dwchadwick, there's the rub, as the bard said 18:43:35 ayoung, +1 18:43:40 so that should be up to the deployment to decide 18:43:55 if you have multiple namespaces, you can chose either: 18:44:06 1. if they leave off the domain ID, they get the default or 18:44:17 2. if you leave off the domain id you get an error 18:44:24 We have gone with 1 18:44:28 ayoung: …they get the domain the token is scoped to…. 18:44:35 as it allows the V2 api to work unchanged 18:44:43 henrynash, right 18:44:54 but you have to start the process somewhere 18:45:24 so if I just pass in userid and password to get a token, and not domain ID, we are saying that is checked against the default domain to keep V2 working 18:45:52 I like that 18:45:52 no 4. But you have to specify the domain name always when you want to use the non-default domain 18:46:00 ayoung: v2 client yes 18:46:03 But, for V3, we can specify that the domain Id is always passed, or we can specify it is up to the deployment whether it is required or not 18:46:15 up to deployment, please 18:46:27 dwchadwick, yes, you have to specify the domain name always when you want to use the non-default domain. 18:46:41 that works 18:47:00 gyee, henrynash do you guys feel like we have a workable solution? 18:47:02 So this issue is not up to the deployment 18:47:17 ayoung, sounds good to me! 18:47:34 dwchadwick, the deployment gets to say whether default domains are in effect, or whether you always have to specify 18:47:37 gyee: The key is that this is a hard: every domain has its own namespace 18:47:48 ayoung yes 18:47:58 I'm fine with that…the rest is details we can work through outside this meeting 18:48:05 dwchadwick, said another way, the deployment controls the rule "what to do if domain ID is missing" 18:48:12 schweet 18:48:33 ayoung : no, the deployment cannot control that 18:48:35 henrynash, hard to implement or hard to understand? :) 18:48:47 gyee: hard as in fixed! 18:48:48 It cannot say domain name is missing and it is private namespace 18:49:06 dwchadwick, I thought we agreed to stop using the word private 18:49:11 but yes, I am not saying that 18:49:14 as recipient then wont know what name it is meant to be 18:49:14 it can say 18:49:29 if no domain id, use a default domain of "EXAMPLE_COM" 18:49:38 agreed 18:49:44 or it can say 18:49:55 if no domain id, raise an exception 18:49:57 but it cannot same if domain is missing, guess which domain it is 18:51:06 dwchadwick, true....although we are specifying that in certain cases, a missing domain ID would mean "carry over the domain id used in a previous transaction with this same user" 18:51:15 heck, young: Ok, sign me up to update the api spec to reflect this 18:51:27 so it has to be specified at some point in the chain. 18:51:55 #action henrynash updates spec to reflect current design of domain namespacing 18:52:17 can you guys approve the current token API spec first? 18:52:34 gyee: whats the review url 18:52:37 gyee: valid point 18:52:39 I'm still a little unclear on domains and namespaces 18:52:57 https://review.openstack.org/#/c/20524/ 18:53:00 gyee: you earned a +1 from me today 18:53:12 topol, thanks 18:53:13 gyee: you'll need to change the wordings to remove private namespaces etc. 18:53:21 gyee you have your approval https://review.openstack.org/#/c/20524/ 18:53:34 grasseyass amigo! 18:53:45 gyee: however, it won't change what you pass, just the text description 18:53:53 is a domain a namespace? 18:54:01 heh, I already hit approve. Should I stop that? 18:54:04 dwaite, yes 18:54:05 dwaite: it is now 18:54:06 ok 18:54:08 yay 18:54:37 henrynash, you can do the wording update after the merge 18:54:44 gyee: +2 18:54:49 w00t! 18:54:52 ayoung: did you review the final result or just hit approve? 18:55:13 dolphm, hit approve. there were +2s from two core 18:55:31 I can stop it 18:55:50 ayoung: please read hugely impactful changes before you sign off on them :( 18:56:01 what's the holdup? 18:56:04 reading back really quick - I very much want a fixed suggested solution for waht happens when no domain is specified. 18:56:12 ayoung - good with your proposal entirely 18:56:22 but it can't be deployment specific, or we'll fuck interoperability 18:57:05 I'm fine with someone choosing to do it another way, but we need (as OpenStack) to have an opinion on the solution and publish it to allow for interop 18:57:07 dolphm, sorry...I just saw that there was the requisite number. We can continue to update the spec, though....I think that it is ok for this to be its own commit 18:57:27 not a bad idea to break big reviews down into smaller ones, as we have seen 18:57:35 right, and henrynash is going to change the wording on namespace 18:57:39 +1 18:57:51 wow, that merged fast 18:58:05 docs have very little build process 18:58:06 henrynash, she's all yours :) 18:58:18 / gating 18:58:23 gyee: I"ll treat her gently... 18:58:57 dolphm, actually, now that I look at it, I had read that earlier. 18:59:28 I was fine by it. It can always be clearer, but I think we are on the right track 18:59:58 Well, there goes that meeting. 19:00:18 dolphm, since I assume heckj is split-brained right now, you want to move on to the next topic, or just call it here 19:00:22 heckj: hey, but agreed stuff! 19:00:36 heckj, ah. we done? 19:00:41 we're out of time, so we'll need to wrap for today 19:00:44 #endmeeting