<p dir="ltr">I thought the agreement was that default would be assumed so that we didn't break backwards compatibility? </p>
<div class="gmail_quote">On Oct 7, 2015 10:35 AM, "Rich Megginson" <<a href="mailto:rmeggins@redhat.com">rmeggins@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<font size="+1">tl;dr You must specify a domain when using domain
scoped resources.<br>
<br>
If you are using domains with puppet-keystone, there is a proposed
patch that will break backwards compatibility.<br>
<br>
<a href="https://review.openstack.org/#/c/226624/" target="_blank">https://review.openstack.org/#/c/226624/</a>
Replace indirection calls<br>
<br>
"Indirection calls are replaced with #fetch_project and
#fetch_user methods<br>
using python-openstackclient (OSC).<br>
<br>
Also removes the assumption that if a resource is unique within a
domain space<br>
then the domain doesn't have to be specified."<br>
<br>
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.<br>
<br>
Here is an example from puppet-heat - the 'heat_admin' user has
been created in the 'heat_stack' domain previously.<br>
<br>
ensure_resource('keystone_user_role',
'heat_admin@::heat_stack", {<br>
'roles' => ['admin'],<br>
})<br>
<br>
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.<br>
<br>
The breakage manifests itself like this, from the logs::<br>
<br>
2015-10-02 06:07:39.574 | Debug: Executing '/usr/bin/openstack
user show --format shell heat_admin --domain Default'<br>
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<br>
<br>
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.<br>
<br>
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 -
<a href="https://review.openstack.org/226919" target="_blank">https://review.openstack.org/226919</a> - so in the near future you
will be able to specify the resource like this:<br>
<br>
</font><br>
<font size="+1"> ensure_resource('keystone_user_role',
'heat_admin@::heat_stack", {<br>
'roles' => ['admin'],<br>
'user_domain_name' => 'heat_stack',<br>
})<br>
<br>
</font>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>