Open Stack

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130807/9d039910/attachment.html>