[placement] [translation] translating exceptions
In placement we've been experimenting with removing oslo_versionedobjects. There's neither RPC nor rolling upgrades in placement so it is effectively overkill and the experiment has revealed that removing it also improves performance. The removal of OVO allows us to remove a lot of transitive dependencies. See https://review.openstack.org/#/c/636807/ where the lower-constraints.txt file is updated to reflect the changes. After those changes the biggest single package remaining in the test virtualenvs is Babel (included via oslo.i18n), weighing in at a mighty 26M. Placement is currently set to enable translation of exception messages, especially those that will end up in API responses. It has no other UI to speak of, so we've begun to wonder about getting rid of translation entirely. I asked about this in the TC office hours[1], which generated some useful but not entirely conclusive discussion. One way to summarize that discussion is that it might be okay to not translate the error messages, because it is unlikely they will be a priority for translators who are more oriented towards docs and UI, and that since no translation has yet happened, if there were ever going to be a time to turn off translation, now would be the time. It is additionally okay because placement is striving to follow the errors guideline [2] and use error.code in error responses, which exist at least in part to make googling for "what do I do when I get this error" a bit easier. That desire to google is also a good reason to keep the error responses in one language. However: We shouldn't do this if people need or want the error responses to be translated. Thus this message. Do people have opinions on this? Is it okay to not translate error responses in an API-only service like placement? Thanks. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-... [2] https://specs.openstack.org/openstack/api-wg/guidelines/errors.html -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
(Added i18n tag) Chris Dent <cdent+os@anticdent.org> writes:
In placement we've been experimenting with removing oslo_versionedobjects. There's neither RPC nor rolling upgrades in placement so it is effectively overkill and the experiment has revealed that removing it also improves performance.
The removal of OVO allows us to remove a lot of transitive dependencies. See https://review.openstack.org/#/c/636807/ where the lower-constraints.txt file is updated to reflect the changes.
After those changes the biggest single package remaining in the test virtualenvs is Babel (included via oslo.i18n), weighing in at a mighty 26M.
Placement is currently set to enable translation of exception messages, especially those that will end up in API responses. It has no other UI to speak of, so we've begun to wonder about getting rid of translation entirely.
I asked about this in the TC office hours[1], which generated some useful but not entirely conclusive discussion.
One way to summarize that discussion is that it might be okay to not translate the error messages, because it is unlikely they will be a priority for translators who are more oriented towards docs and UI, and that since no translation has yet happened, if there were ever going to be a time to turn off translation, now would be the time.
It is additionally okay because placement is striving to follow the errors guideline [2] and use error.code in error responses, which exist at least in part to make googling for "what do I do when I get this error" a bit easier.
That desire to google is also a good reason to keep the error responses in one language.
However: We shouldn't do this if people need or want the error responses to be translated.
Thus this message.
Do people have opinions on this? Is it okay to not translate error responses in an API-only service like placement?
Does an end-user interact with placement directly, or are all of the errors going to be seen and handled by other services that will report their own errors to end users?
Thanks.
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-... [2] https://specs.openstack.org/openstack/api-wg/guidelines/errors.html -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
-- Doug
On 2/21/2019 11:07 AM, Doug Hellmann wrote:
Does an end-user interact with placement directly, or are all of the errors going to be seen and handled by other services that will report their own errors to end users?
The Placement APIs are admin-only by default. That can be configured via policy but assume it's like Ironic and admin-only for the most part. Speaking of, what does Ironic do about translations in its API? As for the question at hand, I'm OK with *not* translating errors in placement for both the admin-only aspect and the push to use standard codes in error responses which can be googled. FWIW I also shared this thread on WeChat to see if anyone has an opinion there. -- Thanks, Matt
Matt Riedemann <mriedemos@gmail.com> writes:
On 2/21/2019 11:07 AM, Doug Hellmann wrote:
Does an end-user interact with placement directly, or are all of the errors going to be seen and handled by other services that will report their own errors to end users?
The Placement APIs are admin-only by default. That can be configured via policy but assume it's like Ironic and admin-only for the most part.
Speaking of, what does Ironic do about translations in its API?
As for the question at hand, I'm OK with *not* translating errors in placement for both the admin-only aspect and the push to use standard codes in error responses which can be googled.
FWIW I also shared this thread on WeChat to see if anyone has an opinion there.
--
Thanks,
Matt
I agree. If placement isn't meant for cloud end-users to interact with, I don't see a lot of benefit to translating the error messages coming through the API. -- Doug
We could play it safe: rip out the dependencies, but keep the macros (and continue to use them for exceptions) and make placement.i18n._() a no-op. That's a hedge against future operators who don't have the background or experience to make this call yet, making it much easier to (re)instate. Eric Fried Concept Brazilian Jiu Jitsu http://taylorbjj.com
On Feb 21, 2019, at 12:56, Doug Hellmann <doug@doughellmann.com> wrote:
Matt Riedemann <mriedemos@gmail.com> writes:
On 2/21/2019 11:07 AM, Doug Hellmann wrote: Does an end-user interact with placement directly, or are all of the errors going to be seen and handled by other services that will report their own errors to end users?
The Placement APIs are admin-only by default. That can be configured via policy but assume it's like Ironic and admin-only for the most part.
Speaking of, what does Ironic do about translations in its API?
As for the question at hand, I'm OK with *not* translating errors in placement for both the admin-only aspect and the push to use standard codes in error responses which can be googled.
FWIW I also shared this thread on WeChat to see if anyone has an opinion there.
--
Thanks,
Matt
I agree. If placement isn't meant for cloud end-users to interact with, I don't see a lot of benefit to translating the error messages coming through the API.
-- Doug
On Thu, 21 Feb 2019, Doug Hellmann wrote:
Matt Riedemann <mriedemos@gmail.com> writes:
As for the question at hand, I'm OK with *not* translating errors in placement for both the admin-only aspect and the push to use standard codes in error responses which can be googled.
[snip]
I agree. If placement isn't meant for cloud end-users to interact with, I don't see a lot of benefit to translating the error messages coming through the API.
I started digging around in this again, and while I agree there's little value in having the messages translated given the reasons Matt states, the driving goal was to shrink the import weight (Babel contributes ~25M (~15%)). However, we can't get that without also removing oslo.i18n (and thus Babel) from: keystoneclient keystonemiddleware oslo.cache oslo.concurrency oslo.config oslo.db oslo.log oslo.middleware oslo.policy oslo.serialization oslo.upgradecheck oslo.utils (Unless those happen to import it conditionally, I wouldn't except them to.) So this is a bit of a non-starter, at least for now and I don't see a ton of point in removing the '_(..)' throughout placement. There might be room for a discussion in the future about where in the stack we encourage dependencies and translation, but how things are now probably makes sense for the vast majority of cases. For people who are trying to keep things small (in containers or wherever) it's quite likely the Babel dat files can be deleted during the container build without breaking things (since placement has no po files). I'll look into that. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
Chris-
So this is a bit of a non-starter, at least for now and I don't see a ton of point in removing the '_(..)' throughout placement.
Except that, if we're not going to do the translating ever, it's just dead code and we may as well remove it. Commented accordingly on https://review.openstack.org/#/c/647412/ efried
On 2/21/19 6:51 PM, Matt Riedemann wrote:
On 2/21/2019 11:07 AM, Doug Hellmann wrote:
Does an end-user interact with placement directly, or are all of the errors going to be seen and handled by other services that will report their own errors to end users?
The Placement APIs are admin-only by default. That can be configured via policy but assume it's like Ironic and admin-only for the most part.
Speaking of, what does Ironic do about translations in its API?
We're trying to keep all user-visible strings translatable.
As for the question at hand, I'm OK with *not* translating errors in placement for both the admin-only aspect and the push to use standard codes in error responses which can be googled.
FWIW I also shared this thread on WeChat to see if anyone has an opinion there.
participants (5)
-
Chris Dent
-
Dmitry Tantsur
-
Doug Hellmann
-
Eric Fried
-
Matt Riedemann