Gilles Dubreuil <gil...@redhat.com> writes:
> On 15/09/15 06:53, Rich Megginson 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.
>>
>
> 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'.
I agree that my example is not similar to what the keystone provider has
to do. What I wanted to point out is that user in puppet should be used
to have this kind of *interface*, one where your put something
meaningful in the title and one where you put something meaningless.
The fact that the meaningful one is a compound one shouldn't matter to
the user.
>>>
>>> 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.
So we should go we the meaningful one first for consistency, I think.
>>> 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> 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
--
Sofer Athlan-Guyot
__________________________________________________________________________
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
