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" <[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. > > 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
