Open Stack

On Mon, Jan 20, 2014 at 10:18 AM, Day, Phil <philip.day at hp.com> wrote:

>  HI Folks,
>
>
>
> The original (and fairly simple) driver behind whole-host-allocation (
> https://wiki.openstack.org/wiki/WholeHostAllocation) 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.   https://etherpad.openstack.org/p/NovaIcehousePcloudsBased 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
>

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.

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,

And for the love of all that is holy in this world, please do not implement
this as yet another API extension.

Best,
-jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140120/7a7be33b/attachment.html>