<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 8/9/13 3:05 PM, Nikolay Starodubtsev
wrote:<br>
</div>
<blockquote
cite="mid:CAAa8YgB9KkoUnhtz38ahjtihKaN+83STvrZPtm8FHVhnPp6nBA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">Hello, Patrick!
<br>
<br>
We have several reasons to think that for the virtual resources
this possibility is interesting. If we speak about physical
resources, user may use them in the different ways, that's why
it is impossible to include base actions with them to the
reservation service. But speaking about virtual reservations,
let's imagine user wants to reserve virtual machine. He knows
everything about it - its parameters, flavor and time to be
leased for. Really, in this case user wants to have already
working (or at least starting to work) reserved virtual machine
and it would be great to include this opportunity to the
reservation service. <br>
</div>
</blockquote>
<blockquote
cite="mid:CAAa8YgB9KkoUnhtz38ahjtihKaN+83STvrZPtm8FHVhnPp6nBA@mail.gmail.com"
type="cite">
<div dir="ltr">We are thinking about base actions for the virtual
reservations that will be supported by Climate, like boot/delete
for instance, create/delete for volume and create/delete for the
stacks. The same will be with volumes, IPs, etc. As for more
complicated behaviour, it may be implemented in Heat. This will
make reservations simpler to use for the end users.
<br>
<br>
Don't you think so?
<br>
</div>
</blockquote>
Well yes and and no. It really depends upon what you put behind
those lease actions. The view I am trying to sustain is separation
of duties to keep the service simple, ubiquitous and non
prescriptive of a certain kind of usage pattern. In other words,
keep Climate for reservation of capacity (physical or virtual), Heat
for orchestration, and so forth. ... Consider for example the case
of reservation as a non technical act but rather as a business
enabler for wholesales activities. Don't need, and probably don't
want to start or stop any resource there. I do not deny that there
are cases where it is desirable but then how reservations are used
and composed together at the end of the day mainly depends on
exogenous factors which couldn't be anticipated because they are
driven by the business.<br>
<br>
And so, rather than coupling reservations with wired resource
instantiation actions, I would rather couple them with notifications
that everybody can subscribe to (as opposed to the Resource Manager
only) which would let users decide what to do with the life-cycle
events. The what to do may very well be what you advocate i.e. start
a full stack of reserved and interwoven resources, or at the other
end of the spectrum, do nothing at all. This approach IMO would keep
things more open. <br>
<blockquote
cite="mid:CAAa8YgB9KkoUnhtz38ahjtihKaN+83STvrZPtm8FHVhnPp6nBA@mail.gmail.com"
type="cite">
<div dir="ltr"> <br>
P.S. Also we remember about the problem you mentioned some
letters ago - how to guarantee that user will have already
working and prepared host / VM / stack / etc. by the time lease
actually starts, no just "lease begins and preparing process
begins too". We are working on it now.<br>
</div>
</blockquote>
Yes. I think I was explicitly referring to hosts instantiation also
because there is no support of that in Nova API. Climate should
support some kind of "reservation kick-in heads-up" notification
whereby the provider and/or some automated provisioning tools could
do the heavy lifting work of bringing physical hosts online before a
hosts reservation lease starts. I think it doesn't have to be
rocket-science either. It's probably sufficient to make Climate fire
up a notification that say "Lease starting in x seconds", x being
an offset value against T0 that could be defined by the operator
based on heuristics. A dedicated (e.g. IPMI) module of the Resource
Manager for hosts reservation would subscribe as listener to those
events. <br>
<blockquote
cite="mid:CAAa8YgB9KkoUnhtz38ahjtihKaN+83STvrZPtm8FHVhnPp6nBA@mail.gmail.com"
type="cite">
<div dir="ltr">
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Aug 8, 2013 at 8:18 PM, Patrick
Petit <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:patrick.petit@bull.net" target="_blank">patrick.petit@bull.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi Nikolay,<br>
<br>
Relying on Heat for orchestration is obviously the right
thing to do. But there is still something in your design
approach that I am having difficulties to comprehend
since the beginning. Why do you keep thinking that
orchestration and reservation should be treated
together? That's adding unnecessary complexity IMHO. I
just don't get it. Wouldn't it be much simpler and
sufficient to say that there are pools of reserved
resources you create through the reservation service.
Those pools could be of different types i.e. host,
instance, volume, network,.., whatever if that's really
needed. Those pools are identified by a unique id that
you pass along when the resource is created. That's it.
You know, the AWS reservation service doesn't even care
about referencing a reservation when an instance is
created. The association between the two just happens
behind the scene. That would work in all scenarios,
manual, automatic, whatever... So, why do you care so
much about this in a first place?<br>
Thanks, <br>
Patrick
<div>
<div class="h5"><br>
On 8/7/13 3:35 PM, Nikolay Starodubtsev wrote:<br>
</div>
</div>
</div>
<div>
<div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div>Patrick, responding to your comments:</div>
<div><br>
</div>
<div>1) Dina mentioned "start automatically" and
"start manually" only as examples of how these
politics may look like. It doesn't seem to be a
correct approach to put orchestration
functionality (that belongs to Heat) in Climate.
That's why now we can implement the basics like
starting Heat stack, and for more complex
actions we may later utilize something like
Convection (Task-as-a-Service) project.</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>2) If we agree that Heat is the main consumer
of Reservation-as-a-Service, we can agree that
lease may be created according to one of the
following scenarions (but not multiple):</div>
<div>- a Heat stack (with requirements to stack's
contents) as a resource to be reserved</div>
<div>- some amount of physical hosts (random ones
or filtered based on certain characteristics). </div>
<div>- some amount of individual VMs OR Volumes OR
IPs </div>
<div><br>
</div>
<div>3) Heat might be the main consumer of virtual
reservations. If not, Heat will require
development efforts in order to support:</div>
<div>- reservation of a stack </div>
<div>- waking up a reserved stack</div>
<div>- performing all the usual orchestration work</div>
<div><br>
</div>
<div>We will support reservation of individual
instance/volume/ IP etc, but the use case with
"giving user already working group of connected
VMs, volumes, networks" seems to be the most
interesting one. </div>
<div>As for Heat autoscaling, reservation of the
maximum instances set in the Heat template (not
the minimum value) has to be implemented in
Heat. Some open questions remain though - like
updating of Heat stack when user changes the
template to support higher max number of running
instances</div>
<div><br>
</div>
<div>4) As a user, I would of course want to have
it already working, running any configured
hosts/stacks/etc by the time lease starts. But
in reality we can't predict how much time the
preparation process should take for every single
use case. So if you have an idea how this should
be implemented, it would be great you share your
opinion.</div>
</div>
</blockquote>
</div>
</div>
<blockquote type="cite">
<div dir="ltr"> </div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a moz-do-not-send="true" href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a moz-do-not-send="true" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Patrick Petit
Cloud Computing Principal Architect, Innovative Products
Bull, Architect of an Open World TM
Tél : +33 (0)4 76 29 70 31
Mobile : +33 (0)6 85 22 06 39
<a class="moz-txt-link-freetext" href="http://www.bull.com">http://www.bull.com</a></pre>
</body>
</html>