<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Nikolay,<br>
Please see comments inline.<br>
Thanks<br>
Patrick<br>
On 8/12/13 5:28 PM, Nikolay Starodubtsev wrote:<br>
</div>
<blockquote
cite="mid:CAAa8YgBxuXTZJ=uJ9TWEh-Y3ZBOuDr=nGwciH9O5=1BQz0Qq2A@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr"><span
id="docs-internal-guid-7979c2fb-7323-8e3c-7844-b1879f212977">
<p dir="ltr"
style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Hi,
again!</span></p>
<br>
<span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span>
<p dir="ltr"
style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Partick,
I’ll try to explain why do we belive in some base actions
like instance starting/deleting in Climate. We are
thinking about the following workflow (that will be quite
comfortable and user friendly, and now we have more than
one customer who really want it):</span></p>
<br>
<span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span>
<p dir="ltr"
style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">1)
User goes to the OpenStack dashboard and asks Heat to
reserve several stacks.</span></p>
<br>
<span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span>
<p dir="ltr"
style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">2)
Heat goes to the Climate and creates all needed leases.
Also Heat reserves all resources for these stacks.</span></p>
<br>
<span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span>
<p dir="ltr"
style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">3)
When time comes, user goes to the OpenStack cloud and here
we think he wants to see already working stacks (ideal
version) or (at least) already started. If no, user will
have to go to the Dashboard and wake up all the stacks he
or she reserved. This means several actions, that may be
done for the user automatically, because it will be needed
to do them no matter what is the aim for these stacks - if
user reserves them, he / she needs them.</span></p>
<br>
<span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span>
<p dir="ltr"
style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">We
understand, that there are situations when these actions
may be done by some other system (like some hypothetical
Jenkins). But if we speak about users, this will be
useful. We also understand that this default way of
behavior should be implemented in some kind of long term
life cycle management system (which is not Heat), but we
have no one in the OpenStack now. Because the best may to
implement it is to use Convection, that is only proposal
now... </span></p>
<br>
<span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span>
<p dir="ltr"
style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">That’s
why we think that for the behavior like “user just
reserves resources and then does anything he / she wants
to” physical leases are better variant, when user may
reserve several nodes and use it in different ways. For
the virtual reservations it will be better to start /
delete them as a default way (for something unusual Heat
may be used and modified).</span></p>
</span></div>
</blockquote>
Okay. So let's bootstrap it this way then. There will be two
different ways the reservation service will deal with reservations
depending on whether its physical or virtual. All things being
equal, future will tell how things settle. We will focus on the
physical host reservation side of things. It think having this
contradictory debate helped to understand each others use cases and
requirements that the initial design has to cope with. Francois who
already submitted a bunch of code for review will not return from
vacation until the end of August. So things on our side are a little
on the standby until he returns but it might help if you could take
a look at it. I suggest you start with your vision and we will
iterate from there. Is that okay with you?<br>
<br>
<blockquote
cite="mid:CAAa8YgBxuXTZJ=uJ9TWEh-Y3ZBOuDr=nGwciH9O5=1BQz0Qq2A@mail.gmail.com"
type="cite">
<div dir="ltr"><span
id="docs-internal-guid-7979c2fb-7323-8e3c-7844-b1879f212977">
<br>
<span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span>
<p dir="ltr"
style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Do
you think that this workflow is useful too and if so can
you propose another implementation variant for it?</span></p>
<br>
<span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span>
<p dir="ltr"
style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Thank
you. </span></p>
<div><span
style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><br>
</span></div>
</span></div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
On Mon, Aug 12, 2013 at 1:55 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 class="im">
<div>On 8/9/13 3:05 PM, Nikolay Starodubtsev wrote:<br>
</div>
<blockquote type="cite">
<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 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>
</div>
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>
<div class="im">
<blockquote 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>
</div>
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>
<div class="im">
<blockquote 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><br>
On 8/7/13 3:35 PM, Nikolay Starodubtsev
wrote:<br>
</div>
</div>
</div>
<div>
<div>
<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>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>