As a quick note, we decided during our weekly meeting to move forward with that patch and accept some use-cases are not backward compatible that time. Reviewers, please look at the code and vote for it.
Thanks, On 10/12/2015 01:53 AM, Gilles Dubreuil wrote: > > > 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 > -- Emilien Macchi
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
