Open Stack

In the case of baremetal in our environment, when a boot attempt fails we
mark that node as being in maintenance mode, which prevents Nova from
scheduling to it a second time. Then automation comes along and files
repair tickets for the bad hardware. Only when a human or other automation
fixes the node and removes the "maintenance" state, will it be available
for scheduling again.

On Mon, May 22, 2017 at 1:25 PM, Eric Fried <openstack at fried.cc> wrote:

> Hey folks, sorry if this is a jejune question, but:
>
> In a no-reschedules-by-nova world, if a deploy fails on host 1, how does
> the orchestrator (whatever that may be) ask nova to deploy in such a way
> that it'll still try to find a good host, but *avoid* host 1?  If host 1
> was an attractive candidate the first time around, wouldn't it be likely
> to remain high on the list the second time?
>
> I'd also like to second the thought that the monolithic "instance in
> error state" gives the orchestrator no hint as to whether the deploy
> failed because of something the orchestrator did (remedy may be to
> redrive with different inputs, but no need to exclude the original
> target host) versus because something went wrong on the compute host
> (remedy would be to retry on a different host with the same inputs).
> Kind of analogous to the difference between HTTP 4xx and 5xx error
> classes.  (Perhaps implying a design whereby the nova API responds to
> the deploy request with different error codes accordingly.)
>
> Thanks,
> efried
> .
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170522/005660a4/attachment.html>