<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 20, 2014 at 10:18 AM, Day, Phil <span dir="ltr"><<a href="mailto:philip.day@hp.com" target="_blank">philip.day@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div link="#0563C1" vlink="#954F72" lang="EN-US">
<div>
<p class="MsoNormal">HI Folks,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The original (and fairly simple) driver behind whole-host-allocation (<a href="https://wiki.openstack.org/wiki/WholeHostAllocation" target="_blank">https://wiki.openstack.org/wiki/WholeHostAllocation</a>) was to enable users to get guaranteed isolation
 for their instances.  This then grew somewhat along the lines of “If they have in effect a dedicated hosts then wouldn’t it be great if the user could also control some aspect of the scheduling, access for other users, etc”.    The Proof of Concept I presented
 at the Icehouse Design summit provided this by providing API extensions to in effect manipulate an aggregate and scheduler filters used with that aggregate.  
<a href="https://etherpad.openstack.org/p/NovaIcehousePclouds" target="_blank">https://etherpad.openstack.org/p/NovaIcehousePclouds</a>Based on the discussion and feedback from the design summit session it became clear that this approach was kind of headed into a difficult middle ground between a very simple approach for users who just wanted the isolation for their instances,
 and a fully delegated admin model which would allow any admin operation to be scoped to a specific set of servers/flavours/instances<u></u><u></u></p></div></div></blockquote><div><br></div><div>My advice would be to steer as clear as you can from any concept based on legacy/traditional managed/dedicated hosting. This means staying away from *any concept* that would give the impression to the user that they own or control some bare-metal resource. This is, after all, a cloud. It isn't dedicated hosting where the customer owns or co-owns the hardware. The cloud is all about on-demand, shared resources. In this case, the "shared resource" is only shared among the one tenant's users, but it's not owned by the tenant. Furthermore, once no longer in use by the tenant, the resource may be re-used by other tenants.<br>
<br>Implementing the concept of EC2 dedicated instances is easy in Nova: simply attach to the request a list of project identifiers in a "limit_nodes_hosting_projects" attribute on the allocation request object. The scheduler would see a non-empty value as an indication that it must only schedule the instance(s) on compute nodes that are only hosting instances owned by one of the projects in that list.d, <br>
<br></div><div>And for the love of all that is holy in this world, please do not implement this as yet another API extension.<br></div><div><br>Best,<br></div><div>-jay<br></div></div></div></div>