Open Stack

Le 20/01/2014 16:57, Jay Pipes a écrit :
> On Mon, Jan 20, 2014 at 10:18 AM, Day, Phil <philip.day at hp.com 
> <mailto: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


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140120/7759ca55/attachment.html>