On 09/14/2015 03:26 PM, Sofer Athlan-Guyot wrote:
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 ?

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

Reply via email to