Hi Ziad,<br><br>Apologies for reviving this old thread, I am changing the subject so that my email doesn't get lost in this big pile.<br><br>We are working on integrating Quantum Network Service with Keystone as the AuthN/Z service provider. I believe you are aware of the prior discussion between you, Salvatore and Vish regarding Keystone's capabilities and Quantum's AuthN/Z use cases.<br>
<br>To recap prior emails, Quantum plans to leverage Keystone for AuthN services, this is simple enough, well understood use case, for which Keystone provides good support. The point of contention has been around Quantum's AuthZ use case.<br>
<br>Quantum's AuthZ use case: <br><br>1) A tenant named Tenant-X( or user with access to Tenant-X) requests that Network-A be created - simple enough, Keystone does AuthN and Quantum associates the particular network with a specific tenant (Tenant-X)<br>
<br>2) Tenant-X( or user with access to Tenant-X) requests that Nova plug a Virtual Network Interface named "instance-0001-eth0" into Network-A<br><br> 2.1) Quantum needs to ensure Tenant-X( or user with access to Tenant-X) owns Network-A - Simple enough, since this network was created in Quantum, Quantum tracks which tenant owns which Quantum resources.<br>
2.2) Quantum needs to ensure Tenant-X( or user with access to Tenant-X) owns Virtual Network Interface named "instance-0001-eth0" available in Nova - <b>This is where we need AuthZ help from Keystone</b><br>
2.3) Quantum needs to ensure Tenant-X( or user with access to Tenant-X) is authorized to perform the "plug_virtual_interface()" operation.<br><br>To solve Quantum's AuthZ use-cases as specified in section 2.2 & 2.3, we have one possible solution using "roles", as was described by you and Vish earlier in the original Keystone API email thread.<br>
<br>Solution: <br><br>1) For every token, that spins up a new VM, on VM and Virtual network interface creation, Nova adds a "role" to the particular tenant( or token?) with the following pattern - nova:plug_vif:<virtual interface id><br>
2) Quantum queries Keystone for roles associated with a particular token( tenant/user) and can then verify if the particular user has authorization over a virtual interface and if the user can perform "plug_vif" operation.<br>
<br>My question to Keystone devs is:<br><br>1) Do you guys see the proposed solution to be compatible with Keystone Diablo API?<br>2) Would you recommend any other solution to Quantum's use-cases based on the Keystone API available in Diablo time-frame.<br>
3) If we implement the above mentioned solution, then we might easily end up with 1 additional role for every virtual interface in Nova, this can easily amount 1000's of roles associated with every tenant as its not unheard of for a Virtual Machine to have 3-4 Virtual Interfaces, and now with multi-nic support, we might see that in OpenStack too.<br>
<br> - Having, for example, 3000 roles per tenant, and having a 1000 tenants would be a reasonable estimate for a medium sized deployment. In such a scenario, will Keystone be able to scale and operate?, do we have any estimates or validation on Keystone's scale numbers?<br>
<br> - If this doesn't work today, what are the limits of the system today?<br> <br> - If Quantum's AuthZ use case cannot be fulfilled with what Keystone API offers in Diablo time-frame, would you know what are the future plans around AuthZ that will help fulfill Quantum's use-cases while not imposing scalability restrictions.<br>
<br><br>Thanks in advance for parsing through this long email and we will look forward to your recommendations.<br><br>Regards,<br><br>Somik<br><br><div class="gmail_quote">On Thu, Jul 21, 2011 at 11:51 AM, Ziad Sawalha <span dir="ltr"><<a href="mailto:ziad.sawalha@rackspace.com">ziad.sawalha@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word;color:rgb(0, 0, 0);font-size:14px;font-family:Calibri, sans-serif">
<div>
<div>Hot, Texas summer regards to all!</div>
<div><br>
</div>
<div>Since my last note we have had much progress on Keystone. Particularly:</div>
<ul>
<li>We now have Nova, Dashboard, Glance, and Keystone integration (<a href="https://github.com/cloudbuilders/deploy.sh" target="_blank">https://github.com/cloudbuilders/deploy.sh</a> </li><li>We've done some work on Swift integration (<a href="https://github.com/rackspace/keystone/blob/master/keystone/middleware/swift_auth.py" target="_blank">https://github.com/rackspace/keystone/blob/master/keystone/middleware/swift_auth.py</a>)</li>
<li>LDAP an be your backend (<a href="https://github.com/rackspace/keystone/pull/102" target="_blank">https://github.com/rackspace/keystone/pull/102</a>)</li><li>We're incubating! Keystone is now officially an OpenStack Incubation project.</li>
<li>And many other updates, enhanced testing, stability improvements, etc…</li></ul>
<div>In my last note I called out our latest API proposal and asked for input. We've received much of that input – thank you - and have four new blueprints to change the API. These are:</div>
<ol>
<li>Support Service Registration (blueprint here <a href="https://blueprints.launchpad.net/keystone/+spec/keystone-service-registration" target="_blank">https://blueprints.launchpad.net/keystone/+spec/keystone-service-registration</a>).</li>
<li>Remove support for 'default' tenant. Instead, a 'Member' or 'default' role can be used to manage a default tenant (this may be implemented in the legacy_token_auth front end (blueprint here: <a href="https://blueprints.launchpad.net/keystone/+spec/remove-default-tenant" target="_blank">https://blueprints.launchpad.net/keystone/+spec/remove-default-tenant</a>). </li>
<li>Support for EC2 API and non-password credentials (blueprint here: <a href="https://blueprints.launchpad.net/keystone/+spec/support-multiple-credentials" target="_blank">https://blueprints.launchpad.net/keystone/+spec/support-multiple-credentials</a>).</li>
<li>Support for API versioning in the service catalog (blueprint here: <a href="https://blueprints.launchpad.net/keystone/+spec/service-catalog-version-support" target="_blank">https://blueprints.launchpad.net/keystone/+spec/service-catalog-version-support</a>).</li>
</ol>
<div></div>
</div>
<div>I'd like to invite comments on those blueprints (here, by email, or on the whiteboards or on the keystone issues list on github. Use the medium you prefer). As well as any new blueprint proposals to change the API.</div>
<div><br>
</div>
<div>I'd also like to propose a date for locking down the 2.0 API for Diablo. We're going to need some time to finish the implementation by feature freeze (Sept 10th), so I'd like to open the debate up for about three weeks and propose we lock down the API
by the end of the weekend of <u><b>August 14th</b></u>.</div>
<div> </div>
<div>Give us your requirements… and let me know if the dates don't work for you or your projects/teams.</div>
<div><br>
</div>
<div>Best,</div>
<div><br>
</div>
<div>Ziad</div>
<div><br>
</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;border-bottom:medium none;border-left:medium none;padding-bottom:0in;padding-left:0in;padding-right:0in;border-top:#b5c4df 1pt solid;border-right:medium none;padding-top:3pt">
<span style="font-weight:bold">From: </span>Ziad Sawalha <<a href="mailto:ziad.sawalha@rackspace.com" target="_blank">ziad.sawalha@rackspace.com</a>><br>
<span style="font-weight:bold">Date: </span>Fri, 10 Jun 2011 18:24:21 -0500<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a>" <<a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a>><br>
<span style="font-weight:bold">Subject: </span>OpenStack Identity: Keystone API Proposal<br>
</div><div class="im">
<div><br>
</div>
<div>
<div style="word-wrap:break-word;color:rgb(0, 0, 0);font-size:14px;font-family:Calibri, sans-serif">
<div>Time flies! It's June 10th already. In my last email to this community I had proposed today as the day to lock down the Keystone API so we can finalize implementation by Diablo-D2 (June 30th).</div>
<div><br>
</div>
<div>We've been working on this feverishly over the past couple of weeks and have just pushed out a proposed API here:
<a href="https://github.com/rackspace/keystone/raw/master/keystone/content/identitydevguide.pdf" target="_blank">
https://github.com/rackspace/keystone/raw/master/keystone/content/identitydevguide.pdf</a></div>
<div><br>
</div>
<div>For any and all interested, the original source and code is on Github (<a href="https://github.com/rackspace/keystone/raw/master/keystone/content/identitydevguide.pdf" target="_blank">https://github.com/rackspace/keystone</a>), along with the current implementation of
Keystone, examples, sample data, tests, instructions, and all the goodies we could muster to put together. The project also lives on Launchpad at
<a href="http://launchpad.net/keystone" target="_blank">http://launchpad.net/keystone</a>.</div>
<div><br>
</div>
<div>The API we just put out there is still a proposal. We're going to be focusing on the implementation, but would still love to get community input, feedback, and participation.</div>
<div><br>
</div>
<div>Have a great weekend and regards to all,</div>
<div><br>
</div>
<div>Ziad</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div></span><div class="im">
<font face="monospace">This email may include confidential information. If you received it in error, please delete it.</font></div></div>
<br>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><font color="#666666">Somik Behera | Nicira Networks, Inc. | </font><a href="mailto:sbehera@nicira.com" target="_blank"><font color="#666666">somik@nicira.com</font></a><font color="#666666"> | office: 650-390-6790 | cell: 512-577-6645</font><br>