Open Stack

New installs run through the migration process of course, so they would end
up with a default domain, even if there's nothing referencing it. The v2
API would not work out of the box, otherwise.

If you didn't want to support the v2 API in your deployment, you'd have to
manually remove the v2-related pipelines from your keystone.conf, and then
you could manually delete the default domain through SQL (if desired --
it's still a valid domain on v3). Attempting to delete it through the v3
API would break the v2 API, hence the desire to deny that behavior and
force a manual process. All of these constraints could be removed in the
Grizzly+2 timeframe, if we see fit to no longer support v2 at all (at that
point, the data migration could be revised to only create a default domain
*if it was necessary based on existing data*, so fresh Grizzly+2 installs
would be empty out of the box).

Alternatively, if you wanted to expose a different domain on v2, you could
also create & configure it on v3, and then set your default_domain_id to
that domain's ID, and then delete the unused 'default' domain through the
API (e.g. DELETE /v3/domains/default). You could use a similar process to
completely circumvent the dont-delete-the-default-domain check.

LDAP support for domains is trailing at the moment, so I'm speaking mostly
with an eye toward SQL, but the default_domain_id will apply there as well
-- we just won't be able to create the domain for you.

All that said, although it's relatively early in the grizzly-m3 cycle, I
don't imagine you will want to deploy Grizzly without v2 support as there
will still be v2 clients in use, even among the core projects.

-Dolph


On Wed, Jan 16, 2013 at 1:57 PM, Brant Knudson <blk at acm.org> wrote:

> Dolph -
>
> The bp mentions migration, but it doesn't mention new installs. Does a new
> install automatically get the default domain?
>
> The bp says that you can also not have a default domain, but the default_
> domain_id configuration option has a default. What do I set the
> configuration option to if I don't have a default domain?
>
> The bp says that an attempt to delete the default domain will result in
> 403 Forbidden. In the case where there is no default domain you should get
> a 404 Not Found rather than 403.
>
> - Brant
>
>
>
> On Tue, Jan 15, 2013 at 2:42 PM, Dolph Mathews <dolph.mathews at gmail.com>wrote:
>
>> Per today's keystone meeting, I wrote a blueprint for the default domain
>> solution, in order to provide an assumed scope for v2 API operations (which
>> is not domain-aware), including authentication and validation, in the
>> context of a deployment with v3 API users (which are domain-aware).
>>
>>   https://blueprints.launchpad.net/keystone/+spec/default-domain
>>
>> Feedback appreciated,
>>
>> -Dolph
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130116/adb649f1/attachment-0001.html>