Open Stack

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.

>
> But, If that's indeed not possible to have them both, 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,