<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 30, 2017 at 3:24 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Jim Rollenhagen's message of 2017-03-30 15:08:13 -0400:<br>
<div><div class="h5">> On Thu, Mar 30, 2017 at 2:36 PM, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>><br>
> wrote:<br>
><br>
> > Excerpts from Sean McGinnis's message of 2017-03-22 10:44:05 -0500:<br>
> > > On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:<br>
> > > > On Tue, 2017-03-21 at 22:10 +0000, Taryma, Joanna wrote:<br>
> > > > > However, pep8 does not accept passing variable to translation<br>
> > > > > functions,  so this results in ‘H701 Empty localization string’<br>
> > error.<br>
> > > > ><br>
> > > > > Possible options to handle that:<br>
> > > > ><br>
> > > > > 1)      Duplicate messages:<br>
> > > > ><br>
> > > > > LOG.error(“<error message>”, {<key>: <val>})<br>
> > > > ><br>
> > > > > raise Exception(_(“<error message>”) % {<key>: <val>})<br>
> > > > ><br>
> > > > > 2)      Ignore this error<br>
> > > > ><br>
> > > > > 3)      Talk to hacking people about possible upgrade of this check<br>
> > > > ><br>
> > > > > 4)      Pass translated text to LOG in such cases<br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > > I’d personally vote for 2. What are your thoughts?<br>
> > > ><br>
> > > > When the translators go to translate, they generally only get to see<br>
> > > > what's inside _(), so #2 is a no-go for translations, and #3 also is a<br>
> > > > no-go.<br>
> > > > --<br>
> > ><br>
> > > I think the appropriate thing here is to do something like:<br>
> > ><br>
> > > msg = _('<error message>') % {<key>: <val>}<br>
> > > LOG.error(msg)<br>
> > > raise Exception(msg)<br>
> > ><br>
> > > This results in a translated string going to the log, but I think that's<br>
> > > OK.<br>
> > ><br>
> ><br>
> > Why is the error being logged and then thrown? If it's a true exception,<br>
> > won't the outer-most part of the application loop log the error? And if<br>
> > it's something that the application is catching and handling, that makes<br>
> > it seem like it's not an operator-facing error.<br>
> ><br>
><br>
> That's a good point. Without looking for examples, I suspect there's a few<br>
> reasons here:<br>
><br>
> 1) in ironic, the operator and API user are often the same person<br>
> 2) ironic deals with hardware. Often, errors that are returned to the user<br>
> are<br>
>    something only the operator can fix.<br>
> 3) Nova is a heavy user of the ironic API - errors returned to nova may not<br>
> be<br>
>    seen by the user, but the operator needs to see it somewhere (though it<br>
>    is easy to argue those shouldn't be translated).<br>
><br>
> // jim<br>
<br>
</div></div>I guess my point was that unhandled exceptions should all be handled<br>
by the Ironic API service code before the response is delivered,<br>
rather than having them handled in the code that is throwing the<br>
exception. If the exception is handled, that makes the message a warning<br>
or info log message, not an error, under our guidelines [1].<br>
<br>
[1] <a href="http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html" rel="noreferrer" target="_blank">http://specs.openstack.org/<wbr>openstack/openstack-specs/<wbr>specs/log-guidelines.html</a></blockquote><div><br></div><div>Fair enough. Maybe the folks removing translations can work on this while they are in the code already. :)</div><div><br></div><div>// jim</div></div></div></div>