On Mon, Sep 14, 2015 at 1:53 PM, Rich Megginson <rmegg...@redhat.com> wrote:
> On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:
>
>> Hi,
>>
>> Gilles Dubreuil <gil...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
