<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 10/07/2015 03:54 PM, Matt Fischer
wrote:<br>
</div>
<blockquote
cite="mid:CAHr1CO8UQcW5ayK3B84viypjPw+Leb+m8qWcX+DtLxxVHaWgLA@mail.gmail.com"
type="cite">
<p dir="ltr">I thought the agreement was that default would be
assumed so that we didn't break backwards compatibility? </p>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:CAHr1CO8UQcW5ayK3B84viypjPw+Leb+m8qWcX+DtLxxVHaWgLA@mail.gmail.com"
type="cite">
<div class="gmail_quote">On Oct 7, 2015 10:35 AM, "Rich Megginson"
<<a moz-do-not-send="true" 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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>