Open Stack

On Mon, Sep 14, 2015 at 1:53 PM, Rich Megginson <rmeggins at redhat.com> 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.
>
>
>> 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.
>
>
I'm not sure I see a benefit to notation like:

      Keystone_tenant { 'foo::blah/bar::is::cool': delimiter => "/", ... }

Overall option below just looks more straightforward (and requires less
logic to convert to something useful). However, I admit I am not an expert
in puppet conventions:

     Keystone_tenant { 'foo::blah" domain => "bar::is::cool'", ... }


--Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150914/cc46a549/attachment.html>