<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body 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 class="moz-txt-link-freetext"
        href="https://review.openstack.org/#/c/226624/">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 class="moz-txt-link-freetext" href="https://review.openstack.org/226919">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>
  </body>
</html>