<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Le 20/01/2014 16:57, Jay Pipes a
écrit :<br>
</div>
<blockquote
cite="mid:CAAE6tVZkD40Jr6029UyCQHCAq6_rYnVKLRv8LWv5Tk62RHkbWQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<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 moz-do-not-send="true"
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,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">The original (and fairly simple)
driver behind whole-host-allocation (<a
moz-do-not-send="true"
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 moz-do-not-send="true"
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</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>
</blockquote>
<br>
<br>
Hi Phil and Jay,<br>
<br>
Phil, maybe you remember I discussed with you about the possibility
of using pclouds with Climate, but we finally ended up using Nova
aggregates and a dedicated filter. That works pretty fine. We don't
use instance_properties but rather aggregate metadata but the idea
remains the same for isolation.<br>
<br>
Jay, please be aware of the existence of Climate, which is a
Stackforge project for managing dedicated resources (like AWS
reserved instances). This is not another API extension, but another
API endpoint for creating what we call "leases" which can be started
now or in the future and last for a certain amount of time. We
personnally think there is a space for Reservations in Openstack,
and this needs to be done as a service.<br>
<br>
-Sylvain<br>
</body>
</html>