Open Stack

Excerpts from Jim Rollenhagen's message of 2017-03-30 15:08:13 -0400:
> On Thu, Mar 30, 2017 at 2:36 PM, Doug Hellmann <doug at doughellmann.com>
> wrote:
> 
> > Excerpts from Sean McGinnis's message of 2017-03-22 10:44:05 -0500:
> > > On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:
> > > > On Tue, 2017-03-21 at 22:10 +0000, Taryma, Joanna wrote:
> > > > > However, pep8 does not accept passing variable to translation
> > > > > functions,  so this results in ‘H701 Empty localization string’
> > error.
> > > > >
> > > > > Possible options to handle that:
> > > > >
> > > > > 1)      Duplicate messages:
> > > > >
> > > > > LOG.error(“<error message>”, {<key>: <val>})
> > > > >
> > > > > raise Exception(_(“<error message>”) % {<key>: <val>})
> > > > >
> > > > > 2)      Ignore this error
> > > > >
> > > > > 3)      Talk to hacking people about possible upgrade of this check
> > > > >
> > > > > 4)      Pass translated text to LOG in such cases
> > > > >
> > > > >
> > > > >
> > > > > I’d personally vote for 2. What are your thoughts?
> > > >
> > > > When the translators go to translate, they generally only get to see
> > > > what's inside _(), so #2 is a no-go for translations, and #3 also is a
> > > > no-go.
> > > > --
> > >
> > > I think the appropriate thing here is to do something like:
> > >
> > > msg = _('<error message>') % {<key>: <val>}
> > > LOG.error(msg)
> > > raise Exception(msg)
> > >
> > > This results in a translated string going to the log, but I think that's
> > > OK.
> > >
> >
> > Why is the error being logged and then thrown? If it's a true exception,
> > won't the outer-most part of the application loop log the error? And if
> > it's something that the application is catching and handling, that makes
> > it seem like it's not an operator-facing error.
> >
> 
> That's a good point. Without looking for examples, I suspect there's a few
> reasons here:
> 
> 1) in ironic, the operator and API user are often the same person
> 2) ironic deals with hardware. Often, errors that are returned to the user
> are
>    something only the operator can fix.
> 3) Nova is a heavy user of the ironic API - errors returned to nova may not
> be
>    seen by the user, but the operator needs to see it somewhere (though it
>    is easy to argue those shouldn't be translated).
> 
> // jim

I guess my point was that unhandled exceptions should all be handled
by the Ironic API service code before the response is delivered,
rather than having them handled in the code that is throwing the
exception. If the exception is handled, that makes the message a warning
or info log message, not an error, under our guidelines [1].

[1] http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html