Open Stack

Okay, are we going to have a document that maps exception classes to
these explanations and recovery actions? Which we then have to maintain
as the code changes? Or are they expected to look through code (without
a stack trace)?

I'm not against the idea, just playing devil's advocate. Sylvain seems
to have a use case, so great.

As an alternative, have we considered a mechanism whereby we could, in
appropriate code paths, provide some text that's expressly intended for
the end user to see? Maybe it's a new user_message field on
NovaException which, if present, gets percolated up to a new field
similar to the one you suggested.

efried

On 11/13/19 11:41 AM, Matt Riedemann wrote:
> On 11/13/2019 11:17 AM, Eric Fried wrote:
>> Unless it's likely to be something other than NoValidHost a significant
>> percentage of the time, IMO it...
> 
> Well just taking resize, it could be one of many things:
> 
> https://github.com/openstack/nova/blob/20.0.0/nova/conductor/manager.py#L366
> - oops you tried resizing which would screw up your group affinity policy
> 
> https://github.com/openstack/nova/blob/20.0.0/nova/compute/manager.py#L4490
> - (for an admin, cold migrate) oops you tried cold migrating a vcenter
> vm or you have allow_resize_to_same_host=True and the scheduler picks
> the same host (silly scheduler, see bug 1748697)
> 
> https://github.com/openstack/nova/blob/20.0.0/nova/compute/claims.py#L113 -
> oops you lost a resource claims race, try again
> 
> https://github.com/openstack/nova/blob/20.0.0/nova/scheduler/client/report.py#L1898
> - oops you lost a race with allocation consumer generation conflicts,
> try again
>