<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 9:06 PM, Scott Devoid wrote:<br>
</div>
<blockquote
cite="mid:CAJrQjSuQ1U0TKZ10y13Dsc8To8pa9+gd4LUqFN+iQOSooZ8SBA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">Hi Nikolay and Patrick, thanks for your replies.
<div><br>
</div>
<div>Virtual vs. Physical Resources</div>
<div>Ok, now I realize what you meant by "virtual resources,"
e.g. instances, volumes, networks...resources provided by
existing OpenStack schedulers. In this case "physical
resources" are actually more "removed" since there are no
interfaces to them in the user-level OpenStack APIs. If you
make a physical reservation on "this rack of machines right
here", how do you supply this reservation information to
nova-scheduler? Probably via scheduler hints + an availability
zone or host-aggregates. At which point you're really defining
a instance reservation that includes explicit scheduler hints.
Am I missing something?</div>
</div>
</blockquote>
<br>
Hi Scott!<br>
No, you don't. At least, it's how I see things working for hosts
reservation. In fact, it is already partially addressed in Havana
with <a class="moz-txt-link-freetext" href="https://wiki.openstack.org/wiki/WholeHostAllocation">https://wiki.openstack.org/wiki/WholeHostAllocation</a>. What's
missing is the ability to automate the create and release of those
pools based on a lease schedule.<br>
Thanks<br>
Patrick <br>
<blockquote
cite="mid:CAJrQjSuQ1U0TKZ10y13Dsc8To8pa9+gd4LUqFN+iQOSooZ8SBA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Eviction:<br>
</div>
<div>Nikolay, to your point that we might evict something that
was already paid for: in the design I have in mind, this would
only happen if the policies set up by the operator caused one
reservation to be weighted higher than another reservation.
Maybe because one client paid more? The point is that this
would be configurable and the sensible default is to not evict
anything.</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Aug 9, 2013 at 8:05 AM, Nikolay
Starodubtsev <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:nstarodubtsev@mirantis.com" target="_blank">nstarodubtsev@mirantis.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<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. 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>
<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>
<div class="HOEnZb">
<div class="h5">
<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>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<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><br>
<br>
</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>