On 10/07/2015 03:54 PM, Matt Fischer wrote:
I thought the agreement was that default would be assumed so that we
didn't break backwards compatibility?
puppet-heat had already started using domains, and had already written
their code based on the implementation where an unqualified name was
allowed if it was unique among all domains. That code will need to
change to specify the domain. Any other code that was already using
domains (which I'm assuming is hardly any, if at all) will also need to
change.
On Oct 7, 2015 10:35 AM, "Rich Megginson" <[email protected]
<mailto:[email protected]>> wrote:
tl;dr You must specify a domain when using domain scoped resources.
If you are using domains with puppet-keystone, there is a proposed
patch that will break backwards compatibility.
https://review.openstack.org/#/c/226624/ Replace indirection calls
"Indirection calls are replaced with #fetch_project and
#fetch_user methods
using python-openstackclient (OSC).
Also removes the assumption that if a resource is unique within a
domain space
then the domain doesn't have to be specified."
It is the last part which is causing backwards compatibility to be
broken. This patch requires that a domain scoped resource _must_
be qualified with the domain name if _not_ in the 'Default'
domain. Previously, you did not have to qualify a resource name
with the domain if the name was unique in _all_ domains. The
problem was this code relied heavily on puppet indirection, and
was complex and difficult to maintain. We removed it in favor of
a very simple implementation: if the name is not qualified with a
domain, it must be in the 'Default' domain.
Here is an example from puppet-heat - the 'heat_admin' user has
been created in the 'heat_stack' domain previously.
ensure_resource('keystone_user_role', 'heat_admin@::heat_stack", {
'roles' => ['admin'],
})
This means "assign the user 'heat_admin' in the unspecified domain
to have the domain scoped role 'admin' in the 'heat_stack'
domain". It is a domain scoped role, not a project scoped role,
because in "@::heat_stack" there is no project, only a domain.
Note that the domain for the 'heat_admin' user is unspecified. In
order to specify the domain you must use
'heat_admin::heat_stack@::heat_stack'. This is the recommended fix
- to fully qualify the user + domain.
The breakage manifests itself like this, from the logs::
2015-10-02 06:07:39.574 | Debug: Executing '/usr/bin/openstack
user show --format shell heat_admin --domain Default'
2015-10-02 06:07:40.505 | Error:
/Stage[main]/Heat::Keystone::Domain/Keystone_user_role[heat_admin@::heat]:
Could not evaluate: No user heat_admin with domain found
This is from the keystone_user_role code. Since the role user was
specified as 'heat_admin' with no domain, the keystone_user_role
code looks for 'heat_admin' in the 'Default' domain and can't find
it, and raises an error.
Right now, the only way to specify the domain is by adding
'::domain_name' to the user name, as
'heat_admin::heat_stack@::heat_stack'. Sofer is working on a way
to add the domain name as a parameter of keystone_user_role -
https://review.openstack.org/226919 - so in the near future you
will be able to specify the resource like this:
ensure_resource('keystone_user_role', 'heat_admin@::heat_stack", {
'roles' => ['admin'],
'user_domain_name' => 'heat_stack',
})
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
