[openstack-dev] [puppet][keystone] Keystone resource naming with domain support - no '::domain' if 'Default'

Rich Megginson rmeggins at redhat.com
Thu Aug 27 14:53:51 UTC 2015


On 08/27/2015 07:00 AM, Gilles Dubreuil wrote:
>
> On 27/08/15 22:40, Gilles Dubreuil wrote:
>>
>> On 27/08/15 16:59, Gilles Dubreuil wrote:
>>>
>>> On 26/08/15 06:30, Rich Megginson wrote:
>>>> This concerns the support of the names of domain scoped Keystone
>>>> resources (users, projects, etc.) in puppet.
>>>>
>>>> At the puppet-openstack meeting today [1] we decided that
>>>> puppet-openstack will support Keystone domain scoped resource names
>>>> without a '::domain' in the name, only if the 'default_domain_id'
>>>> parameter in Keystone has _not_ been set.  That is, if the default
>>>> domain is 'Default'.  In addition:
>>>>
>>>> * In the OpenStack L release, if 'default_domain_id' is set, puppet will
>>>> issue a warning if a name is used without '::domain'.
>> The default domain is always set to 'default' unless overridden to
>> something else.
> Just to clarify, I don't see any logical difference between the
> default_domain_id to be 'default' or something else.

There is, however, a difference between explicitly setting the value to 
something other than 'default', and not setting it at all.

That is, if a user/operator specifies

   keystone_domain { 'someotherdomain':
     is_default => true,
   }

then the user/operation is explicitly telling puppet-keystone that a 
non-default domain is being used, and that the user/operator is aware of 
domains, and will create domain scoped resources with the '::domain' in 
the name.

>
> Per keystone.conf comment (as seen below) the default_domain_id,
> whatever its value, is created as a valid domain.
>
> # This references the domain to use for all Identity API v2 requests
> (which are not aware of domains). A domain with this ID will be created
> for you by keystone-manage db_sync in migration 008. The domain
> referenced by this ID cannot be deleted on the v3 API, to prevent
> accidentally breaking the v2 API. There is nothing special about this
> domain, other than the fact that it must exist to order to maintain
> support for your v2 clients. (string value)
> #default_domain_id = default
>
> To be able to test if a 'default_domain_id' is set or not, actually
> translates to checking if the id is 'default' or something else.

Not exactly.  There is a difference between explicitly setting the 
value, and implicitly relying on the default 'default' value.

> But I don't see the point here. If a user decides to change default' to
> 'This_is_the_domain_id_for_legacy_v2", how does this help?

If the user changes that, then that means the user has also decided to 
explicitly provided '::domain' in all domain scoped resource names.

>
> If that makes sense then I would actually avoid the intermediate stage:
>
> * In OpenStack L release:
> Puppet will issue a warning if a name is used without '::domain'.
>
> * From Openstack M release:
> A name must be used with '::domain'.
>
>>>> * In the OpenStack M release, puppet will issue a warning if a name is
>>>> used without '::domain', even if 'default_domain_id' is not set.
>> Therefore the 'default_domain_id' is never 'not set'.
>>
>>>> * In N (or possibly, O), resource names will be required to have
>>>> '::domain'.
>>>>
>> I understand, from Openstack N release and ongoing, the domain would be
>> mandatory.
>>
>> So I would like to revisit the list:
>>
>> * In OpenStack L release:
>>    Puppet will issue a warning if a name is used without '::domain'.
>>
>> * In OpenStack M release:
>>    Puppet will issue a warning if a name is used without '::domain'.
>>
>> * From Openstack N release:
>>    A name must be used with '::domain'.
>>
>>
>>> +1
>>>
>>>> The current spec [2] and current code [3] try to support names without a
>>>> '::domain' in the name, in non-default domains, provided the name is
>>>> unique across _all_ domains.  This will have to be changed in the
>>>> current code and spec.
>>>>
>>> Ack
>>>
>>>> [1]
>>>> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-08-25-15.01.html
>>>>
>>>> [2]
>>>> http://specs.openstack.org/openstack/puppet-openstack-specs/specs/kilo/api-v3-support.html
>>>>
>>>> [3]
>>>> https://github.com/openstack/puppet-keystone/blob/master/lib/puppet/provider/keystone_user/openstack.rb#L217
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>
>> __________________________________________________________________________
>> 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




More information about the OpenStack-dev mailing list