<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 19, 2013 at 6:11 PM, SHAH, Ronak (Ronak R) <span dir="ltr"><<a href="mailto:ronak_r.shah@alcatel-lucent.com" target="_blank">ronak_r.shah@alcatel-lucent.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">Hi,<u></u><u></u></p>
<p class="MsoNormal">I understand the scope of the domain as a high level container in for projects, users and groups by referring @
<a href="https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md" target="_blank">
https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md</a><u></u><u></u></p>
<p class="MsoNormal">In current os services while accessing CLI such as nova, quantum etc, we have been asked about –os-username  and –os-tenant-name.
<u></u><u></u></p>
<p class="MsoNormal">Do we have plan to extend to extend that to provide something like –os-domain-name as well?</p></div></div></blockquote><div><br></div><div style>Yes, exactly. My current proposal for the v3 API in keystoneclient is to assume a default domain ID of 'default' if neither an ID or name are provided.</div>
<div style><br></div><div style>As part of a data migration, keystone is creating a 'default' domain (optionally configurable in keystone.conf), and attaching all existing projects and users to that domain. In a single-domain deployment, user's won't have to specify a domain at all (as the 'default' domain will be accurately assumed). In a multi-domain deployment, users will be required to specify a domain, unless they want to use the default domain.</div>
<div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal">
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">My use-case involves me to have this object available in quantum while performing CRUD on any quantum object. Today I have tenant and user. I would also like to have domain in v3.
<u></u><u></u></p>
<p class="MsoNormal">One way to do is probably use quantumclient. But if we are creating namespace for it and passing along in context, beautiful!</p></div></div></blockquote><div><br></div><div style>When auth_token is v3-aware, I expect it to start providing a domain ID + name in the wsgi environment, along with user ID + name, etc. I'm curious why you're interested in having the domain available in quantum though?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Please let me know.<br>
<br>
Thanks,<u></u><u></u></p>
<p class="MsoNormal">Ronak<u></u><u></u></p>
</div>
</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>