On 08/10/15 07:17, Rich Megginson wrote: > 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. > >
Patch for puppet-heat: https://review.openstack.org/232366 The indirection patch depends on it and both would have to be merged together. >> On Oct 7, 2015 10:35 AM, "Rich Megginson" <[email protected] >> <mailto:[email protected]>> 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. >> Matt, The current implementation is *real* pain and slowing us down. >> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
