Open Stack

On 29 May 2015 at 17:10, Chris Friesen <chris.friesen at windriver.com> wrote:
> On 05/29/2015 06:27 AM, John Garbutt wrote:
>>
>> On 27 May 2015 at 23:36, Robert Collins <robertc at robertcollins.net> wrote:
>>>
>>> On 26 May 2015 at 03:37, Chris Friesen <chris.friesen at windriver.com>
>>> wrote:
>
>
>>>> Basically the problem is this:
>>>>
>>>> When booting up instances, nova allows the user to specify a "min count"
>>>> and
>>>> a "max count".  So logically, this request should be considered
>>>> successful
>>>> if at least "min count" instances can be booted.
>>>>
>>>> Currently, if the user has quota space for "max count" instances, then
>>>> nova
>>>> will try to create them all. If any of them can't be scheduled, then the
>>>> creation of all of them will be aborted and they will all be put into an
>>>> error state.
>
>
>> The problem here is having a nice way to explicitly tell the users
>> about what worked and what didn't. Currently the instance being in an
>> error state because its the "good" way to tell the user that build
>> failed. Deleting them doesn't have the same visibility, it can look
>> like the just vanished.
>
> Fair enough.  But we should only put the ones we couldn't schedule into an
> error state, not the ones that we could schedule (assuming we could schedule
> at least "min_count" instances).

+1

Eek, I missed that detail.
It makes sense to fix that, I think.
I feel a functional test coming on (eventually).

>> Having said all that, I am very tempted to say we should deprecate the
>> "min_count" parameter in the API, keep the current behaviour for old
>> version requests, and maybe even remove the "max_count" parameter. We
>> could look to Heat to do a much better job of this kind of
>> orchestration. This is very much in the spirit of:
>>
>> http://docs.openstack.org/developer/nova/devref/project_scope.html#no-more-orchestration
>
> I'm totally in favour of doing a microversion bump and removing both
> "min_count" and "max_count" and saying if you want multiple instances then
> let something outside of nova handle it.

I think thats a spec worth thinking about.
It needs more through, but I like the idea of that.

>> Either which way, given the impact of the bug fix (i.e. it touches the
>> API, and would probably need a micro version bump), I think it would
>> be great to actually write up your proposal as a nova-spec (backlog or
>> targeted at liberty, either way is cool). I think a spec review would
>> be a great way to reach a good agreement on the best approach here.
>>
>>
>> Chris, does that sounds like an approach that would work for you?
>
> I'm happy to write up a spec to remove "min_count" and "max_count" and bump
> the microversion.

Awesome, thank you.

> I don't think the bugfix for the current API version should have a
> microversion bump.  I think this is a case of "Fixing a bug so that a
> request which resulted in an error response before is now successful." from
> "http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html"
>
> The user asked for between "min_count" and "max_count" instances.  If we can
> schedule at least "min_count" instances then we should do that and not give
> them nothing just because we couldn't schedule "max_count" instances.

+1

There is a case to be made that a bump would indicate the bug was
fixed, but we are yet to actually decide on those these details.
Apologies for this slow down, while we look for some examples and slow
down to document our approach.

Thanks,
John