Open Stack

Hi Sylvain,

Thanks for your comments.  I can see that Climate is aiming to provide a reservation service for physical and now virtual resources also like you mention.

The Instance-group [a][b] effort   (proposed during the last summit,  and good progress has been made so far)  attempts to address the tenant facing API aspects in the bigger Smart Resource Placement puzzle [c].
The idea is to be able to represent an entire topology (a group of resources) that is requested by the tenant, that contains members or sub-groups , their connections,  their associated policies and other metadata.

The first part is to be able to persist this group, and use the group to create/schedule the resources together as a whole group, so that intelligent decisions can be made together considering all the requirements and constraints (policies).

In the ongoing discussions in the Nova scheduler sub-team, we do agree that we need additional support to achieve the creation of the group as a whole.   It will involve reservation too to achieve this.

Once the Instance group is registered and persisted,  we can trigger the creation/boot up of the instances, which will involve arriving at the resource placement decisions and then the actual creation.  So one of the idea is to provide clear apis such an external component (such as climate, heat, or some other module) can take the placement decision results and do the actual creation of resource.

As described in [c], we will also need the support of a global state repository to make all the resource states from across services available to smart placement decision engine.

As part of the plan for [c],  the first step is to tackle the representation and API for these InstanceGroups, and that is this ongoing effort within the Nova Scheduler sub-team.

Our idea to separate the phases of this grand scale scheduling of resources, and keep the interfaces clean.  If we have to interface with Climate for the final creation (I.e., once the smart placement decisions have been made), we should be able to do that, at least that is the vision.


References
[a]Instance Group Model and API extension doc -  https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing<https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing>
[b] Instance group blueprint - https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension
[c] Smart Resource Placement  https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit

Thanks,
Yathi.





From: Sylvain Bauza <sylvain.bauza at bull.net<mailto:sylvain.bauza at bull.net>>
Date: Tuesday, October 8, 2013 12:40 AM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Cc: Yathiraj Udupi <yudupi at cisco.com<mailto:yudupi at cisco.com>>
Subject: Re: [openstack-dev] [scheduler] APIs for Smart Resource Placement - Updated Instance Group Model and API extension model - WIP Draft

Hi Yathi,

Le 08/10/2013 05:10, Yathiraj Udupi (yudupi) a écrit :
Hi,

Based on the discussions we have had in the past few scheduler sub-team meetings,  I am sharing a document that proposes an updated Instance Group Model and API extension model.
This is a work-in-progress draft version, but sharing it for early feedback.
https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing

This model support generic instance types, where an instance can represent a virtual node of any resource type.  But in the context of Nova, an instance refers to the VM instance.

This builds on the existing proposal for Instance Group Extension as documented here in this blueprint:  https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension

Thanks,
Yathi.



Well, I actually read the design document, and I'm strongly interested in jumping to the project.
We started a few months ago a Stackforge project, called Climate [0], aiming to reserve both physical and virtual resources. Initially, the project came from a blueprint targeting only physical reservations [1], and then Mirantis folks joined us having a new usecase for virtual reservations (potentially implementing deferred starts, as said above).

Basically, the physical host reservation is not about deferred starts of instances, it's about grouping for a single tenant a list of hosts, in other words a whole host allocation (see [2]).

We'll provide to end-users a Reservation API allowing to define policies for selecting hosts based on their capabilities [3] and then create host aggregates (or "Pclouds" if we implement [2]). Actually, we could define some policies in the Climate host aggregate for affinity and network-proximity policies, so that any VM to boot from one of these hosts would be applied these host aggregate policies.

As you maybe see, there are some concerns which are close in between your BP [4] and our vision of Climate. What are your thoughts about it ?

[0] : https://github.com/stackforge/climate
[1] : https://wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api
[2] : https://wiki.openstack.org/wiki/WholeHostAllocation
[3] : https://docs.google.com/document/d/1U36k5wk0sOUyLl-4Cz8tmk8RQFQGWKO9dVhb87ZxPC8/edit#heading=h.ujapi6o0un65
[4] : https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131008/54f530d6/attachment.html>