Open Stack

On 09/14/2015 03:26 PM, Sofer Athlan-Guyot wrote:
> Rich Megginson <rmeggins at redhat.com> writes:
>
>> I think we could support both.  I don't see it as an either/or
>> situation.
> +1
>
>>>> 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']
>>      ...
>>    }
>>
> Thanks, I see the point.
>
>>>>     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.
> I don't get this point.  what is "2 or more resource could exists" and
> how it relates to compound names ?

I would like to uniquely specify a resource by the _combination_ of the 
name + the domain.  For example:

   keystone_user { 'domain A admin user':
     name => 'admin',
     domain => 'domainA',
   }

   keystone_user { 'domain B admin user':
     name => 'admin',
     domain => 'domainB',
   }

Puppet doesn't like this - the value of the 'name' property of 
keystone_user is not unique throughout the manifest/catalog, even though 
both users are distinct and unique because they existing in different 
domains (and will have different UUIDs assigned by Keystone).

Gilles posted links to discussions about how to use isnamevar and 
title_patterns with Puppet Ruby providers, but I could not get it to 
work.  I was using Puppet 3.8 - perhaps it only works in Puppet 4.0 or 
later.  At any rate, this is an area for someone to do some research

>
>>>>       - More difficult to debug
>> More difficult than it is already? :P
> require 'pry';binding.pry :)

Tried that on Fedora 22 (actually - debugger pry because pry by itself 
isn't a debugger, but a REPL inspector).  Didn't work.

Also doesn't help you when someone hands you a pile of Puppet logs . . .

>
>>> 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.
> Done there: https://bugs.launchpad.net/puppet-keystone/+bug/1495691

Thanks!

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