Open Stack

On 28/08/15 00:53, Rich Megginson wrote:
> 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.
> 

That makes sense.

Let's chase down the default 'default' domain then.

>>
>> 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
> 
> 
> __________________________________________________________________________
> 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