Open Stack

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?

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.


On Thu, Aug 8, 2013 at 8:18 PM, Patrick Petit <patrick.petit at 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 listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130809/f121ed33/attachment.html>