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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
