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