Open Stack

I thought the agreement was that default would be assumed so that we didn't
break backwards compatibility?
On Oct 7, 2015 10:35 AM, "Rich Megginson" <rmeggins at redhat.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151007/fbe3d487/attachment.html>