Rich Megginson <rmegg...@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-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 -- 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