Open Stack

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