File: user_project_user_role_composite_namevar.pp

package info (click to toggle)
puppet-module-keystone 25.0.0-4
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 2,428 kB
  • sloc: ruby: 9,684; pascal: 295; python: 38; makefile: 10; sh: 10
file content (156 lines) | stat: -rw-r--r-- 4,127 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
# 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
}