Open Stack

On 15/09/15 06:53, Rich Megginson wrote:
> On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:
>> Hi,
>>
>> Gilles Dubreuil <gilles at redhat.com> writes:
>>
>>> A. The 'composite namevar' approach:
>>>
>>>     keystone_tenant {'projectX::domainY': ... }
>>>   B. The 'meaningless name' approach:
>>>
>>>    keystone_tenant {'myproject': name='projectX', domain=>'domainY',
>>> ...}
>>>
>>> Notes:
>>>   - Actually using both combined should work too with the domain
>>> supposedly overriding the name part of the domain.
>>>   - Please look at [1] this for some background between the two
>>> approaches:
>>>
>>> The question
>>> -------------
>>> Decide between the two approaches, the one we would like to retain for
>>> puppet-keystone.
>>>
>>> Why it matters?
>>> ---------------
>>> 1. Domain names are mandatory in every user, group or project. Besides
>>> the backward compatibility period mentioned earlier, where no domain
>>> means using the default one.
>>> 2. Long term impact
>>> 3. Both approaches are not completely equivalent which different
>>> consequences on the future usage.
>> I can't see why they couldn't be equivalent, but I may be missing
>> something here.
> 
> I think we could support both.  I don't see it as an either/or situation.
> 
>>
>>> 4. Being consistent
>>> 5. Therefore the community to decide
>>>
>>> Pros/Cons
>>> ----------
>>> A.
>> I think it's the B: meaningless approach here.
>>
>>>    Pros
>>>      - Easier names
>> That's subjective, creating unique and meaningful name don't look easy
>> to me.
> 
> The point is that this allows choice - maybe the user already has some
> naming scheme, or wants to use a more "natural" meaningful name - rather
> than being forced into a possibly "awkward" naming scheme with "::"
> 
>   keystone_user { 'heat domain admin user':
>     name => 'admin',
>     domain => 'HeatDomain',
>     ...
>   }
> 
>   keystone_user_role {'heat domain admin user@::HeatDomain':
>     roles => ['admin']
>     ...
>   }
> 
>>
>>>    Cons
>>>      - Titles have no meaning!
> 
> They have meaning to the user, not necessarily to Puppet.
> 
>>>      - Cases where 2 or more resources could exists
> 
> This seems to be the hardest part - I still cannot figure out how to use
> "compound" names with Puppet.
> 
>>>      - More difficult to debug
> 
> More difficult than it is already? :P
> 
>>>      - Titles mismatch when listing the resources (self.instances)
>>>
>>> B.
>>>    Pros
>>>      - Unique titles guaranteed
>>>      - No ambiguity between resource found and their title
>>>    Cons
>>>      - More complicated titles
>>> My vote
>>> --------
>>> I would love to have the approach A for easier name.
>>> But I've seen the challenge of maintaining the providers behind the
>>> curtains and the confusion it creates with name/titles and when not sure
>>> about the domain we're dealing with.
>>> Also I believe that supporting self.instances consistently with
>>> meaningful name is saner.
>>> Therefore I vote B
>> +1 for B.
>>
>> My view is that this should be the advertised way, but the other method
>> (meaningless) should be there if the user need it.
>>
>> So as far as I'm concerned the two idioms should co-exist.  This would
>> mimic what is possible with all puppet resources.  For instance you can:
>>
>>    file { '/tmp/foo.bar': ensure => present }
>>
>> and you can
>>
>>    file { 'meaningless_id': name => '/tmp/foo.bar', ensure => present }
>>
>> The two refer to the same resource.
> 
> Right.
> 

I disagree, using the name for the title is not creating a composite
name. The latter requires adding at least another parameter to be part
of the title.

Also in the case of the file resource, a path/filename is a unique name,
which is not the case of an Openstack user which might exist in several
domains.

I actually added the meaningful name case in:
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074325.html

But that doesn't work very well because without adding the domain to the
name, the following fails:

keystone_tenant {'project_1': domain => 'domain_A', ...}
keystone_tenant {'project_1': domain => 'domain_B', ...}

And adding the domain makes it a de-facto 'composite name'.

>>
>> But, If that's indeed not possible to have them both,

There are cases where having both won't be possible like the trusts, but
why not for the resources supporting it.

That said, I think we need to make a choice, at least to get started, to
have something working, consistently, besides exceptions. Other options
to be added later.

>> then I would keep only the meaningful name.
>>
>>
>> As a side note, someone raised an issue about the delimiter being
>> hardcoded to "::".  This could be a property of the resource.  This
>> would enable the user to use weird name with "::" in it and assign a "/"
>> (for instance) to the delimiter property:
>>
>>    Keystone_tenant { 'foo::blah/bar::is::cool': delimiter => "/", ... }
>>
>> bar::is::cool is the name of the domain and foo::blah is the project.
> 
> That's a good idea.  Please file a bug for that.
> 
>>
>>> Finally
>>> ------
>>> Thanks for reading that far!
>>> To choose, please provide feedback with more pros/cons, examples and
>>> your vote.
>>>
>>> Thanks,
>>> Gilles
>>>
>>>
>>> PS:
>>> [1] https://groups.google.com/forum/#!topic/puppet-dev/CVYwvHnPSMc
>>>
>>> __________________________________________________________________________
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> Bye,
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev