<div dir="ltr"><div>Scott, thank you so much for taking part in our discussion!</div><div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><div>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?</div>
<div><br></div><div>2b) +1 Patrick, we saw this type of lease in your BP, could you please describe your use cases for this reservation type?</div><div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
</div>