Open Stack

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" <rmeggins at redhat.com 
> <mailto: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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> 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/9e22eb4c/attachment.html>