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.p...
- oops you lost a race with allocation consumer generation conflicts,
try again