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