Hi, again!
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):
1) User goes to the OpenStack dashboard and asks Heat to reserve
several stacks.
2) Heat goes to the Climate and creates all needed leases. Also
Heat reserves all resources for these stacks.
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.
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...
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).
Do you think that this workflow is useful too and if so can you
propose another implementation variant for it?
Thank you.
On Mon, Aug 12, 2013 at 1:55 PM, Patrick Petit
<patrick.pe...@bull.net <mailto:patrick.pe...@bull.net>> wrote:
On 8/9/13 3:05 PM, Nikolay Starodubtsev wrote:
Hello, Patrick!
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.
Don't you think so?
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.
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.
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.
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.
On Thu, Aug 8, 2013 at 8:18 PM, Patrick Petit
<patrick.pe...@bull.net <mailto:patrick.pe...@bull.net>> wrote:
Hi Nikolay,
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?
Thanks,
Patrick
On 8/7/13 3:35 PM, Nikolay Starodubtsev wrote:
Patrick, responding to your comments:
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.
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):
- a Heat stack (with requirements to stack's contents)
as a resource to be reserved
- some amount of physical hosts (random ones or
filtered based on certain characteristics).
- some amount of individual VMs OR Volumes OR IPs
3) Heat might be the main consumer of virtual
reservations. If not, Heat will require development
efforts in order to support:
- reservation of a stack
- waking up a reserved stack
- performing all the usual orchestration work
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.
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
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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
