Open Stack

Hi Yathi,

Thanks for having taken time explaining your vision.

Climate is about reservations, ie. preempting resources capacity and 
granting a user he will actually get exclusive access to a certain set 
of resources he asks for a certain period of time.
The resource placement decisions are the core of the added-value of 
Climate, as historically we found that we need to do some efficiency on 
it. In other words, we will need to implement a Climate scheduler for 
picking up the right hosts best fitting the user requirements.

In other words, provided an user (or a service) hits the Climate Host 
Reservation API asking for X hosts with these capabilities (and that 
could/should include network bandwidth or host architecture), Climate 
will create a host group (we call it "pcloud") on the lease creation 
with no hosts in it, and after a certain period of time (based on 
efficiency criterias - as of Climate v1 at lease start), Climate will 
take user requirements, elect the hosts and put them in the pcloud.


That said, that's still a bit unclear to me but I would find two points 
where your efforts and our efforts could be joined :
  1/ Climate could be seen as a broker for managing the states of the 
Instance Group by offering a backend system for implementing the need of 
a reservation system
  2/ Climate could also see the Smart Resource Placement holder as an 
"scheduler" for helping to decide which hosts are the best opportunity 
in terms of efficiency


What do you think about it ?
-Sylvain



Le 09/10/2013 01:51, Yathiraj Udupi (yudupi) a écrit :
> 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/20131009/974c3e80/attachment.html>