Open Stack

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 at lists.openstack.org
> http://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/20130808/112e38ba/attachment.html>