Le 20/01/2014 16:57, Jay Pipes a écrit :
On Mon, Jan 20, 2014 at 10:18 AM, Day, Phil <philip....@hp.com
<mailto:philip....@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
Hi Phil and Jay,
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.
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.
-Sylvain
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
