Open Stack

Scott, thank you so much for taking part in our discussion!

0) Introducing the eviction mechanism is really interesting idea, it
potentially makes reservation service more flexible and well organized. But
we need to think about the case - if user, who has already created a
reservation, has lower priority, he will lose this reservation because of
more prioritized request. This may not work well if the reservation was
paid for.

1) Yes, we think it is better too. What do you think about our vision of
Heat being the main consumer of virtual reservations? Do you think the
support of reservations for individual items of resources/groups of
same-type resources is necessary?

2a) I think that letting user to make a reservation of just resources he or
she wants to should not be a problem. Could you please talk more about your
idea about reservation flavors and their usage?

2b) +1 Patrick, we saw this type of lease in your BP, could you please
describe your use cases for this reservation type?

2c) Actually we were speaking about manual and automated starting of
virtual resources usage (like starting VMs when lease starts). Scott, we
think that Patrick can be right speaking about users willing to know if the
requested resources will be granted or not. The prioritization problem is
connected with what you are speaking about in the 0th point.

3) With our new vision, reservations won't be nested. They'll just contain
stack / some amount of hosts / some amount of identical instances (last
item - if we agree that it's needed).

5) Within our vision user is supposed to know whether the resources will be
granted or not right after lease is created. Amazons scheme is different,
that's why they have priorities and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130807/8907c4c8/attachment.html>