openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

On Aug 10, 2012, at 6:24 AM, Patrick Petit <patrick.michel.petit@xxxxxxxxx> wrote:

> Hi,
> So, if I paraphrase correctly what is meant out of the stacker jargon.
> 
> min_count and max_count doc will go in the API doc as an extension item once the DisableServerExtension cleanup is done. Right?


Correct.

> 
> However, the original question was about the num_instances property of the RPC request spec. I do not see a direct relationship with min_count and max_count. So, is num_instances another undocumented API extension parameter or something else?

The RPC code is internal and undocumented at the moment. The num_instances parameter is generated from min_count and max_count based on quota:

399         num_instances, quota_reservations = self._check_num_instances_quota(
400                 context, instance_type, min_count, max_count)

so if you have min_count = 3, max_count = 9:
whith a quota of 10 you num_instances = 5
with a quota of 10, num_instances = 9
with a quota of 2, you will get a QuotaExceeded exception.

I hope that clarifies things.

> 
> I can see also that DisableServerExtensions proposal mentions a reservation_id parameter... Can someone explain what it is ? Is it to support server reservation like in AWS EC2? And so, would a user be able to create a reservation (that is, not to actually create the reserve servers but to reserve the) with say additional min_count max_count parameters in the request. The reservation would fail if min_count cannot be honored by OpenStack. If the reservation can be honored, would return a reservation_id along with a value between min_count and max_count. Is this a correct understanding of the behavior or complete speculation?

return_reservation_id will tell the server create request to return reservation_ids instead of a single server instance, it will be part of the os-multiple-instances extension along with min_count and max_count:

https://review.openstack.org/#/c/11090/

Vish