Open Stack

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 ?

>>>      - More difficult to debug
>
> More difficult than it is already? :P

require 'pry';binding.pry :)

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

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

-- 
Sofer Athlan-Guyot