Hi, A lot of changes has taken place under the hood of those three providers in the keystone module: - keystone_user; - keystone_tenant; - keystone_user_role;
This note will highlight the changes. This has two goals: - make a broader range of puppet users aware of the change and the new syntax now available to them (the old syntax is of course still supported and not planned for deprecation); - give ideas to puppet developer when creating a provider; For those not interested in the details, you can have a quick overview of the new syntax available to puppet user here [1]. Related is the complete review of the default domain behavior there [2]. For the other read on. First thing first, what is composite namevar ? In short, it's the ability in puppet to define a Type with several "keys" not, just the resource's name (think isnamevar). That's it for the short definition. Now, why this change has taken place at all? With the arrival of domain scope in Keystone V3, two main problems appeared. First how to have the domain specified and second and related to the first how to get the default domain for retro-compatibility with Keystone v2. I won't write about the latter here. A full description of the choices made for the past, current and future is there [2]. For the former, a strict title scheme was chosen. For instance to create "user_one" in domain "domain_one" you had to do this: keystone_user { 'user_one::domain_one': ensure => present } For user_role this scheme was chosen for domain scope: keystone_user_role { 'user_one::domain_one@::domain_one': ensure => present, roles => ['admin'] } and this one for project scope: keystone_user_role { 'user_one::domain_one@project_one::domain_one': ensure => present, roles => ['admin'] } The basic problem was that, you couldn't have meaningless name[4], with a syntax like this: keystone_user { 'meanlinglesstitle': name => 'user_one', domain => 'domain_one', ensure => present, } or in a more natural way: keystone_user { 'user_one': domain => 'domain_one', ensure => present, } So to be able to have the three ways, we turn to composite namevar. A puppet feature that let you have several "keys" to identify a resource, not just its name. It leads to the syntax described in [1], which offer far more flexibility in the naming scheme. On the coding side, it leads to some big refactor. For instance all the default_domain handling is done in one place only. The resource's name can now be fully calculated at puppet compile catalog time, removing the need to wait for a full keystone installation to try and guess the default domain. The parsing of the name is done in the type definition file only. The dependencies between the resource have a predictable name (think autorequire). Now, for the puppet coder thinking about making a new resource Type/Provider where the name has to be parsed or the natural key of the resource is a composite one, the composite namevar solution is a something to linger on. The detail of the implementation in keystone are there [3]. See for instance the /lib/puppet/type/keystone_user.rb and lib/puppet/provider/keystone_user/openstack.rb files. Beware though, that a bug in pending on the puppetlab side if you use prefetch in your resource definition. The detail there [5]. It is solved in the module in [6] That's all folks, [1] https://review.openstack.org/244846 [2] https://etherpad.openstack.org/p/keystone_no_domain [3] https://review.openstack.org/226919 [4] http://lists.openstack.org/pipermail/openstack-dev/2015-September/074185.html [5] https://tickets.puppetlabs.com/browse/PUP-5302 [6] https://review.openstack.org/#/c/226919/47/lib/puppet_x/keystone/composite_namevar/helpers/utilities.rb -- 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