<div dir="ltr">On Fri, Sep 11, 2015 at 4:25 AM, Gilles Dubreuil <span dir="ltr"><<a href="mailto:gilles@redhat.com" target="_blank">gilles@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<br>
On 11/09/15 20:17, David Chadwick wrote:<br>
> Whichever approach is adopted you need to consider the future and the<br>
> longer term objective of moving to fully hierarchical names. I believe<br>
> the current Keystone approach is only an interim one, as it only<br>
> supports partial hierarchies. Fully hierarchical names has been<br>
> discussed in the Keystone group, but I believe that this has been<br>
> shelved until later in order to get a quick fix released now.<br>
><br>
> regards<br>
><br>
> David<br>
><br>
<br>
</span>Thanks David,<br>
<br>
That's interesting.<br>
So sub projects are pushing the issue further down.<br>
And maybe one day sub domains and sub users?<br>
<br>
keystone_role_user {<br>
'user.subuser::domain1@project.subproject.subsubproject::domain2':<br>
roles => [...]<br>
}<br>
<br>
or<br>
<br>
keystone_role_user {'user.subuser':<br>
  user_domain => 'domain1',<br>
  tenant => 'project.subproject',<br>
  tenant_domain => 'domain2',<br>
  roles => [...]<br>
}<br>
<br>
I tend to think the domain must stick with the name it's associated<br>
with, otherwise we have to say 'here the domain for this and that, etc'.<br>
<div class=""><div class="h5"><br>
<br>
<br>
> On 11/09/2015 08:03, Gilles Dubreuil wrote:<br>
>> Hi,<br>
>><br>
>> Today in the #openstack-puppet channel a discussion about the pro and<br>
>> cons of using domain parameter for Keystone V3 has been left opened.<br>
>><br>
>> The context<br>
>> ------------<br>
>> Domain names are needed in Openstack Keystone V3 for identifying users<br>
>> or groups (of users) within different projects (tenant).<br>
>> Users and groups are uniquely identified within a domain (or a realm as<br>
>> opposed to project domains).<br>
>> Then projects have their own domain so users or groups can be assigned<br>
>> to them through roles.<br>
>><br>
>> In Kilo, Keystone V3 have been introduced as an experimental feature.<br>
>> Puppet providers such as keystone_tenant, keystone_user,<br>
>> keystone_role_user have been adapted to support it.<br>
>> Also new ones have appeared (keystone_domain) or are their way<br>
>> (keystone_group, keystone_trust).<br>
>> And to be backward compatible with V2, the default domain is used when<br>
>> no domain is provided.<br>
>><br>
>> In existing providers such as keystone_tenant, the domain can be either<br>
>> part of the name or provided as a parameter:<br>
>><br>
>> A. The 'composite namevar' approach:<br>
>><br>
>>    keystone_tenant {'projectX::domainY': ... }<br>
>>  B. The 'meaningless name' approach:<br>
>><br>
>>   keystone_tenant {'myproject': name='projectX', domain=>'domainY', ...}<br>
>><br>
>> Notes:<br>
>>  - Actually using both combined should work too with the domain<br>
>> supposedly overriding the name part of the domain.<br>
>>  - Please look at [1] this for some background between the two approaches:<br>
>><br>
>> The question<br>
>> -------------<br>
>> Decide between the two approaches, the one we would like to retain for<br>
>> puppet-keystone.<br>
>><br>
>> Why it matters?<br>
>> ---------------<br>
>> 1. Domain names are mandatory in every user, group or project. Besides<br>
>> the backward compatibility period mentioned earlier, where no domain<br>
>> means using the default one.<br>
>> 2. Long term impact<br>
>> 3. Both approaches are not completely equivalent which different<br>
>> consequences on the future usage.<br>
>> 4. Being consistent<br>
>> 5. Therefore the community to decide<br>
>><br>
>> The two approaches are not technically equivalent and it also depends<br>
>> what a user might expect from a resource title.<br>
>> See some of the examples below.<br>
>><br>
>> Because OpenStack DB tables have IDs to uniquely identify objects, it<br>
>> can have several objects of a same family with the same name.<br>
>> This has made things difficult for Puppet resources to guarantee<br>
>> idem-potency of having unique resources.<br>
>> In the context of Keystone V3 domain, hopefully this is not the case for<br>
>> the users, groups or projects but unfortunately this is still the case<br>
>> for trusts.<br>
>><br>
>> Pros/Cons<br>
>> ----------<br>
>> A.<br>
>>   Pros<br>
>>     - Easier names<br>
>>   Cons<br>
>>     - Titles have no meaning!<br>
>>     - Cases where 2 or more resources could exists<br>
>>     - More difficult to debug<br>
>>     - Titles mismatch when listing the resources (self.instances)<br>
>><br>
>> B.<br>
>>   Pros<br>
>>     - Unique titles guaranteed<br>
>>     - No ambiguity between resource found and their title<br>
>>   Cons<br>
>>     - More complicated titles<br>
>><br>
>> Examples<br>
>> ----------<br>
>> = Meaningless name example 1=<br>
>> Puppet run:<br>
>>   keystone_tenant {'myproject': name='project_A', domain=>'domain_1', ...}<br>
>><br>
>> Second run:<br>
>>   keystone_tenant {'myproject': name='project_A', domain=>'domain_2', ...}<br>
>><br>
>> Result/Listing:<br>
>><br>
>>   keystone_tenant { 'project_A::domain_1':<br>
>>     ensure  => 'present',<br>
>>     domain  => 'domain_1',<br>
>>     enabled => 'true',<br>
>>     id      => '7f0a2b670f48437ba1204b17b7e3e9e9',<br>
>>   }<br>
>>    keystone_tenant { 'project_A::domain_2':<br>
>>     ensure  => 'present',<br>
>>     domain  => 'domain_2',<br>
>>     enabled => 'true',<br>
>>     id      => '4b8255591949484781da5d86f2c47be7',<br>
>>   }<br>
>><br>
>> = Composite name example 1  =<br>
>> Puppet run:<br>
>>   keystone_tenant {'project_A::domain_1', ...}<br>
>><br>
>> Second run:<br>
>>   keystone_tenant {'project_A::domain_2', ...}<br>
>><br>
>> # Result/Listing<br>
>>   keystone_tenant { 'project_A::domain_1':<br>
>>     ensure  => 'present',<br>
>>     domain  => 'domain_1',<br>
>>     enabled => 'true',<br>
>>     id      => '7f0a2b670f48437ba1204b17b7e3e9e9',<br>
>>    }<br>
>>   keystone_tenant { 'project_A::domain_2':<br>
>>     ensure  => 'present',<br>
>>     domain  => 'domain_2',<br>
>>     enabled => 'true',<br>
>>     id      => '4b8255591949484781da5d86f2c47be7',<br>
>>    }<br>
>><br>
>> = Meaningless name example 2  =<br>
>> Puppet run:<br>
>>   keystone_tenant {'myproject1': name='project_A', domain=>'domain_1', ...}<br>
>>   keystone_tenant {'myproject2': name='project_A', domain=>'domain_1',<br>
>> description=>'blah'...}<br>
>><br>
>> Result: project_A in domain_1 has a description<br>
>><br>
>> = Composite name example 2  =<br>
>> Puppet run:<br>
>>   keystone_tenant {'project_A::domain_1', ...}<br>
>>   keystone_tenant {'project_A::domain_1', description => 'blah', ...}<br>
>><br>
>> Result: Error because the resource must be unique within a catalog<br>
>><br>
>> My vote<br>
>> --------<br>
>> I would love to have the approach A for easier name.<br>
>> But I've seen the challenge of maintaining the providers behind the<br>
>> curtains and the confusion it creates with name/titles and when not sure<br>
>> about the domain we're dealing with.<br>
>> Also I believe that supporting self.instances consistently with<br>
>> meaningful name is saner.<br>
>> Therefore I vote B<br>
>><br>
>> Finally<br>
>> ------<br>
>> Thanks for reading that far!<br>
>> To choose, please provide feedback with more pros/cons, examples and<br>
>> your vote.<br>
>><br>
>> Thanks,<br>
>> Gilles<br></div></div></blockquote><div><br></div><div>Please keep in mind that there are no "reserved" characters in projects and/or domains. It is possible to have "::" in both or ":" (or any other random entries), which couple make the composite namevar less desirable in some cases. I expect this to be a somewhat edge case (as using :: in a domain and/or project in places where it would impact the split would be somewhat odd); it can likely also be stated that using puppet requires avoiding the '::' or ':' in this manner.</div><div><br></div><div>I am always a fan of explicit variables personally. It is "more complex" but it is also explicit. This just eliminates ambiguity.</div><div><br></div><div>--Morgan</div></div><br></div></div>