The problem with puppet-keystone and Keystone v3 domains is naming of
puppet resources contained within domains - users, groups, projects.
Suppose you have an admin user in domain "dom1" and an admin user in
domain "dom2". How do you declare these in puppet? You can't do
keystone_user { 'admin': domain => 'dom1'}
and
keystone_user { 'admin': domain => 'dom2'}
AFAIK, resource names in puppet have to be unique. I have introduced
the string "::" as the domain delimiter in puppet code. This allows you
to "fully qualify" resource names with the domain in all domain scoped
resources.
keystone_user { 'admin::dom1': }
and
keystone_user { 'admin': domain => 'dom2'}
This is a valid puppet manifest - the resource names are unique.
How do I refer to the "admin" user? For example, I want to have a role
assignment:
keystone_user_role { 'admin::dom2@project::somedomain': roles =>
['adminrole'] }
How do I have an autorequire for the user? That is, I can't know, in
the autorequire method in the keystone_user_role.rb type code, if the
resource name is going to be 'admin' or 'admin::dom2'. If I just do
autorequire for ['admin'], that will cause problems if a) there is no
'admin' user because all 'admin' users are fully qualified b) the user
named 'admin' is the one in dom1
I could avoid using autorequire and force the use of explicit requires
=> 'name' in every keystone_user_role, but that would break existing
manifests.
I could use autorequire, but force manifest writers to be consistent
with fully qualified resource naming. That is, the manifest writer
would have to know that the resource name of the admin user in dom1 is
always 'admin::dom1' and the resource name of the admin user in dom2 is
always 'admin', and they must be used that way, consistently,
everywhere, even in deeply nested classes/defines.
Another problem is with the puppet provider self.instances method. This
method queries all of the external resources of a given type and
constructs something like a named puppet resource representing the
external resource. For example: the keystone_user self.instances does
'openstack user list --long' and creates named puppet resources.
What happens if openstack user list --long returns admin in dom1 and
admin in dom2? How does self.instances name these uniquely? If it
always names these "fully qualified" with ::domain, this will cause
problems. This could be handled with some extra logic:
1) If name is unique (i.e. there is only one user named 'admin' in all
domains), then just create the resource with the name 'admin' - no
::domain. This would require self.instances to keep track of every
returned resource e.g. collect all of the list results in a hash, and
only instantiate the resources once it is known that the name is unique.
2) If the resource is in the designated "default domain" (i.e. the
domain id matches [identity] default_domain_id, or 'default' if
[identity] default_domain_id not configured), then use the name without
the domain
2 seems like the intuitive way to go - works well with existing
manifests which are not yet domain aware, and things like puppet
resource keystone_user [name] will almost always work as expected. But
this means that manifest writers have to know that all puppet-keystone
manifests and code need to know what the domain name corresponding to
the default_domain_id is, and know that the resource in that domain
should always be referred to as 'name', not 'name::domain'. For
example, if you have user 'someuser' in domain 'Default', and domain
'Default' is the default domain with an id of 'default', all resources
should should use keystone_user { 'name': } and keystone_user_role {
'name@project': }
self.instances could return the fully qualified name _and_ the short
name, where the short name is the resource in the default domain. This
might cause confusion with puppet resource 'resource_name', when the
user sees both 'admin' and 'admin::dom1' but at least the user will see
one or the other, and both "puppet resource keystone_user admin" and
"puppet resource keystone_user admin::dom1" will work. This would
require some minor adjustment to the currently proposed patches for the
self.instances - self.instances would need to be aware of the default
domain and construct short names for those resources, and self.prefetch
would also need to know to use the shortnamed resource for the default
domain. In this case, the short name would be an "alias" for the fully
qualified name, sort of like a dns query where both the shortnames and
fqdns are returned.
__________________________________________________________________________
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
