<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Yathi,<br>
<br>
Thanks for having taken time explaining your vision.<br>
<br>
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.<br>
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.<br>
<br>
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.<br>
<br>
<br>
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 :<br>
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<br>
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<br>
<br>
<br>
What do you think about it ?<br>
-Sylvain<br>
<br>
<br>
<br>
Le 09/10/2013 01:51, Yathiraj Udupi (yudupi) a écrit :<br>
</div>
<blockquote
cite="mid:2AB0F5F851B5644A9B0AA69323D1100538F82F0A@xmb-aln-x15.cisco.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>Hi Sylvain, </div>
<div> </div>
<div>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. </div>
<div><br>
</div>
<div>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]. </div>
<div>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. </div>
<div><br>
</div>
<div>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). </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div><br>
</div>
<div>References </div>
<div>[a]Instance Group Model and API extension doc - <a
moz-do-not-send="true"
href="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</a></div>
<div>[b] Instance group blueprint - <a moz-do-not-send="true"
href="https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension"
id="docs-internal-guid-6aeceba6-9a75-0db4-7644-eb400f512c32"
style="text-decoration: none; "><span style="font-size: 16px;
font-family: Cambria; color: rgb(0, 0, 255);
text-decoration: underline; vertical-align: baseline; ">https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension</span></a></div>
<span style="font-size: 16px; font-family: Cambria;
vertical-align: baseline; "></span>
<div>[c] Smart Resource Placement <span style="text-decoration:
underline; font-size: 16px; font-family: Cambria; color:
rgb(0, 0, 255); vertical-align: baseline; "><a
moz-do-not-send="true"
href="https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit"
id="docs-internal-guid-6aeceba6-9a76-de2e-c51d-3309b0c1db06"
style="text-decoration: none; ">https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit</a> </span></div>
<div><span style="text-decoration: underline; font-size: 16px;
font-family: Cambria; color: rgb(0, 0, 255); vertical-align:
baseline; "><br>
</span></div>
<div>Thanks,</div>
<div>Yathi. </div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt;
text-align:left; color:black; BORDER-BOTTOM: medium none;
BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT:
0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;
BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Sylvain Bauza
<<a moz-do-not-send="true"
href="mailto:sylvain.bauza@bull.net">sylvain.bauza@bull.net</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, October
8, 2013 12:40 AM<br>
<span style="font-weight:bold">To: </span>OpenStack
Development Mailing List <<a moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Cc: </span>Yathiraj Udupi <<a
moz-do-not-send="true" href="mailto:yudupi@cisco.com">yudupi@cisco.com</a>><br>
<span style="font-weight:bold">Subject: </span>Re:
[openstack-dev] [scheduler] APIs for Smart Resource Placement
- Updated Instance Group Model and API extension model - WIP
Draft<br>
</div>
<div><br>
</div>
<div>
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Yathi,<br>
<br>
Le 08/10/2013 05:10, Yathiraj Udupi (yudupi) a écrit :<br>
</div>
<blockquote
cite="mid:2AB0F5F851B5644A9B0AA69323D1100538F6CB51@xmb-aln-x15.cisco.com"
type="cite">
<div>Hi, </div>
<div><br>
</div>
<div>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. </div>
<div>This is a work-in-progress draft version, but sharing
it for early feedback. </div>
<div><a moz-do-not-send="true"
href="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</a> </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>This builds on the existing proposal for Instance
Group Extension as documented here in this blueprint: <a
moz-do-not-send="true"
href="https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension">https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension</a> </div>
<div><br>
</div>
<div>Thanks,</div>
<div>Yathi. </div>
</blockquote>
<br>
<br>
<br>
Well, I actually read the design document, and I'm strongly
interested in jumping to the project.
<br>
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).<br>
<br>
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]).<br>
<br>
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.<br>
<br>
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 ?<br>
<br>
[0] : <a moz-do-not-send="true"
href="https://github.com/stackforge/climate">https://github.com/stackforge/climate</a><br>
[1] : <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api">https://wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api</a><br>
[2] : <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://wiki.openstack.org/wiki/WholeHostAllocation">
https://wiki.openstack.org/wiki/WholeHostAllocation</a><br>
[3] : <a moz-do-not-send="true"
href="https://docs.google.com/document/d/1U36k5wk0sOUyLl-4Cz8tmk8RQFQGWKO9dVhb87ZxPC8/edit#heading=h.ujapi6o0un65">https://docs.google.com/document/d/1U36k5wk0sOUyLl-4Cz8tmk8RQFQGWKO9dVhb87ZxPC8/edit#heading=h.ujapi6o0un65</a><br>
[4] : <a moz-do-not-send="true"
href="https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension">https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension</a><br>
</div>
</div>
</span>
</blockquote>
<br>
</body>
</html>