<div dir="ltr">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.<div><br>
</div><div>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).</div>
<div><br></div><div style>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.</div>
<div><br></div><div>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.<br>
<div class="gmail_extra"><div><div><br></div><div style>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.</div>
<div><br></div>-Dolph</div>
<br><br><div class="gmail_quote">On Wed, Jan 16, 2013 at 1:57 PM, Brant Knudson <span dir="ltr"><<a href="mailto:blk@acm.org" target="_blank">blk@acm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Dolph -<div><br></div><div><div>The bp mentions migration, but it doesn't mention new installs. Does a new install automatically get the default domain?</div><div><br></div><div>The bp says that you can also not have a default domain, but the <span style="color:rgb(51,51,51);font-family:sans-serif;font-size:12px;line-height:18px">default_</span><span style="color:rgb(51,51,51);font-family:sans-serif;font-size:12px;line-height:18px">domain_</span><span style="color:rgb(51,51,51);font-family:sans-serif;font-size:12px;line-height:18px">id </span>configuration option has a default. What do I set the configuration option to if I don't have a default domain?</div>
<div><br></div><div>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.</div><span class=""><font color="#888888"><div>
<br></div><div>
- Brant</div><div><br></div></font></span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Tue, Jan 15, 2013 at 2:42 PM, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">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).<div>
<br></div><div> <a href="https://blueprints.launchpad.net/keystone/+spec/default-domain" target="_blank">https://blueprints.launchpad.net/keystone/+spec/default-domain</a></div><div><br></div><div>Feedback appreciated,<br clear="all">
<div>
<div><br></div>-Dolph</div>
</div></div>
<br></div></div><div class="im">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></div></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div>