Open Stack

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 at doughellmann.com> wrote:
> 
> Matt Riedemann <mriedemos at 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
>