[nova] Thoughts on exposing exception type to non-admins in instance action event

Tom Barron tpb at dyncloud.net
Thu Nov 14 14:30:38 UTC 2019

On 13/11/19 14:38 -0600, Eric Fried wrote:
>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.

Would this be like the "user messages" provided by block [1] and file 
[2] storage components?

[1] https://docs.openstack.org/cinder/latest/contributor/user_messages.html
[2] https://docs.openstack.org/manila/latest/contributor/user_messages.html

-- Tom

>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

More information about the openstack-discuss mailing list