7f951d9716
It was using "::" instead of "@" in the example documentation, see[1]. [1] https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/type/keystone_user_role.rb#L169..L170 Change-Id: I75f7373a8949c862b77c5ae8fa2322c8dd074ff8
157 lines
4.0 KiB
Puppet
157 lines
4.0 KiB
Puppet
# Examples of the new interface to user, project (tenant), and
|
|
# user_role.
|
|
#
|
|
# The new interface does not rely on a unique title scheme and offers
|
|
# the possibility to pass required arguments as parameters. Old
|
|
# interface with everything defined in the title is still supported,
|
|
# but the parsing is more consistent and less error prone (on the
|
|
# coding side). Puppet will find matching resource irrespective of
|
|
# how you create it.
|
|
|
|
# For user you have those choices
|
|
keystone_user { 'user_one':
|
|
ensure => present,
|
|
domain => 'domain_one',
|
|
}
|
|
|
|
# is identical to
|
|
|
|
keystone_user { 'user_one::domain_one': ensure => present }
|
|
|
|
# Note, that parameter override title paring. So:
|
|
keystone_user { 'user_one::domain_two':
|
|
ensure => present,
|
|
domain => 'domain_one'
|
|
}
|
|
|
|
# will create the user in the domain_one, not domain_two.
|
|
|
|
# This led to the meaningless title feature. This can be helpful for
|
|
# manifest/hiera created by another program for instance, where the
|
|
# title could be some random id:
|
|
|
|
keystone_user { 'meanlinglesstitle':
|
|
ensure => present,
|
|
user => 'user_one',
|
|
domain => 'domain_one'
|
|
}
|
|
|
|
# This works for user, project and, with a twist, for user_role, where
|
|
# the title must always have some form. See below.
|
|
|
|
# For project:
|
|
|
|
keystone_tenant { 'project_one':
|
|
ensure => present,
|
|
domain => 'domain_one'
|
|
}
|
|
|
|
# is identical to
|
|
|
|
keystone_tenant { 'project_one::domain_one': ensure => present }
|
|
|
|
# For user_role:
|
|
|
|
# 1: for associating a role to an user in a project scope.
|
|
keystone_user_role { 'user_one@project_one':
|
|
ensure => present,
|
|
user_domain => 'domain_one',
|
|
project_domain => 'domain_two',
|
|
roles => ['admin']
|
|
}
|
|
|
|
# all the way to
|
|
keystone_user_role { 'user_one::domain_one@project_one::domain_two':
|
|
ensure => present,
|
|
roles => ['admin']
|
|
}
|
|
# and all combinations in between.
|
|
|
|
# Note that parameter override the title parsing, so:
|
|
keystone_user_role { 'user_one::domain_one@project_one::domain_one':
|
|
ensure => present,
|
|
project_domain => 'domain_two',
|
|
roles => ['admin']
|
|
}
|
|
|
|
# will match the project project_one::domain_two, not
|
|
# project_one::domain_one. It is also true for keystone_user and
|
|
# keystone_tenant.
|
|
|
|
# You cannot define:
|
|
keystone_user_role { 'user_one':
|
|
ensure => present,
|
|
user_domain => 'domain_one',
|
|
project => 'project_one',
|
|
project_domain => 'domain_two',
|
|
roles => ['admin']
|
|
}
|
|
|
|
# this will trigger an error. You need the '::'
|
|
|
|
# 2: for associating a role to an user in a domain scope.
|
|
keystone_user_role { 'user_one@::domain':
|
|
ensure => present,
|
|
user_domain => 'domain_one',
|
|
roles => ['admin']
|
|
}
|
|
|
|
# is identical to
|
|
keystone_user_role { 'user_one::domain_one@::domain_one':
|
|
ensure => present,
|
|
roles => ['admin']
|
|
}
|
|
|
|
# But, you cannot define:
|
|
keystone_user_role { 'meaningless_title':
|
|
ensure => present,
|
|
user => 'user_one',
|
|
user_domain => 'domain_one',
|
|
domain => 'domain_one',
|
|
roles => ['admin']
|
|
}
|
|
|
|
# this will trigger an error, you need the '::@'
|
|
|
|
# But, there is a way to have meaningless title for user_role.
|
|
|
|
# 1: user role to project.
|
|
keystone_user_role { 'meaningless::meaningless':
|
|
ensure => present,
|
|
user => 'user_one',
|
|
user_domain => 'domain_one',
|
|
project => 'project_one',
|
|
project_domain => 'domain_one',
|
|
roles => ['admin']
|
|
}
|
|
|
|
# 2: user role to domain
|
|
keystone_user_role { 'meaningless::@meaningless':
|
|
ensure => present,
|
|
user => 'user_one',
|
|
user_domain => 'domain_one',
|
|
domain => 'project_one',
|
|
roles => ['admin']
|
|
}
|
|
|
|
# Finally it should be noted that specifying an domain and a project
|
|
# scope at the same time is an error.
|
|
keystone_user_role { 'user_one@::domain_one':
|
|
ensure => present,
|
|
user_domain => 'domain_one',
|
|
project => 'project_one',
|
|
project_domain => 'domain_two',
|
|
roles => ['admin']
|
|
}
|
|
# is an error, and will trigger one.
|
|
|
|
|
|
# NOTE: for the all examples above to work you have to define:
|
|
keystone_domain { 'domain_one':
|
|
ensure => present
|
|
}
|
|
|
|
keystone_domain { 'domain_two':
|
|
ensure => present
|
|
}
|