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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
