Open Stack

Le 29/05/2015 14:27, John Garbutt a écrit :
> 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:
>>> Hi all,
>>>
>>> I've just opened a bug around booting multiple instances at once, and it was
>>> suggested on IRC that I mention it here to broaden the discussion around the
>>> ideal behaviour.
>>>
>>> The bug is at:  https://bugs.launchpad.net/nova/+bug/1458122
>>>
>>> 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 new quota ideas we discussed should make other options for this a
> lot simpler, I think:
> https://review.openstack.org/#/c/182445/
> But lets skip over that for now...
>
>>> Arguably, if nova was able to schedule at least "min count" instances (which
>>> defaults to 1) then it should continue on with creating those instances that
>>> it was able to schedule. Only if nova cannot create at least "min count"
>>> instances should nova actually consider the request as failed.
>>>
>>> Also, I think that if nova can't schedule "max count" instances, but can
>>> schedule at least "min count" instances, then it shouldn't put the
>>> unscheduled ones into an error state--it should just delete them.
>> I think taking successfully provisioned vm's and rolling them back is
>> poor, when the users request was strictly met- I'm in favour of your
>> proposals.
> 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.
>
> We do have a (straw man) proposed solution for this. See the Task API
> discussion here:
> https://etherpad.openstack.org/p/YVR-nova-error-handling
>
> Given this also impacts discussions around cancelling operations like
> live-migrate, I would love for a sub group to form and push forward
> the important work on building a "Task API". I think Andrew Laski has
> committed to writing up a backlog spec for this current proposal (that
> has gained a lot of support), so it could be taken on by some others
> who want to move this forward. Do you fancy getting involved with
> that?

Count me in as well, since I'm interested in contributing to the Tasks 
API (by the level of free time I have :-) )
I will discuss with Andrew once he's back from holidays to see when we 
can setup a subteam meeting for wrapping that up.

That said, all of that has nothing to do with the original question IIUC 
since it's a conductor/scheduler problem and not a quota issue.

>
> 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
>
>
> 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.

100% agreed with John, we should just drop the min-count parameter and 
just leave as deprecated the max-count parameter.

Chris, happy with writing the spec ?

-Sylvain


>
> Chris, does that sounds like an approach that would work for you?
>
>
> Thanks,
> John
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev