Open Stack

On 15/09/15 19:55, Sofer Athlan-Guyot wrote:
> Gilles Dubreuil <gilles at 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 <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'.
> 
> 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.
> 

There is a big blocker of making use of domain name as parameter.
The issue is the limitation of autorequire.

Because autorequire doesn't support any parameter other than the
resource type and expects the resource title (or a list of) [1].

So for instance, keystone_user requires the tenant project1 from
domain1, then the resource name must be 'project1::domain1' because
otherwise there is no way to specify 'domain1':

autorequire(:keystone_tenant) do
  self[:tenant]
end

Alternatively, as Sofer suggested (in a discussion we had), we could
poke the catalog to retrieve the corresponding resource(s).
Unfortunately, unless there is a way around, that doesn't work because
no matter what autorequire wants a title.


So it seems for the scoped domain resources, we have to stick together
the name and domain: '<name>::<domain>'.

[1]
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type.rb#L2003

>>>>
>>>> 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
>>>>>