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.ba...@bull.net
<mailto:sylvain.ba...@bull.net>>
Date: Tuesday, October 8, 2013 12:40 AM
To: OpenStack Development Mailing List
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Cc: Yathiraj Udupi <yud...@cisco.com <mailto:yud...@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
