Open Stack

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" <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.
>>>
> 
> 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: OpenStack-dev-request at 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
> 

-- 
Emilien Macchi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151013/4a729d0d/attachment.pgp>