Mailing List Archive: Dropping lazy translation support

Dropping lazy translation support

Nov 5, 2018, 9:51 AM

Post #1 of 7 (864 views)

This is a follow up to a dev ML email [1] where I noticed that some
implementations of the upgrade-checkers goal were failing because some
projects still use the oslo_i18n.enable_lazy() hook for lazy log message
translation (and maybe API responses?).

The very old blueprints related to this can be found here [2][3][4].

If memory serves me correctly from my time working at IBM on this, this
was needed to:

1. Generate logs translated in other languages.

2. Return REST API responses if the "Accept-Language" header was used
and a suitable translation existed for that language.

#1 is a dead horse since I think at least the Ocata summit when we
agreed to no longer translate logs since no one used them.

#2 is probably something no one knows about. I can't find end-user
documentation about it anywhere. It's not tested and therefore I have no
idea if it actually works anymore.

I would like to (1) deprecate the oslo_i18n.enable_lazy() function so
new projects don't use it and (2) start removing the enable_lazy() usage
from existing projects like keystone, glance and cinder.

Are there any users, deployments or vendor distributions that still rely
on this feature? If so, please speak up now.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-November/136285.html
[2] https://blueprints.launchpad.net/oslo-incubator/+spec/i18n-messages
[3] https://blueprints.launchpad.net/nova/+spec/i18n-messages
[4] https://blueprints.launchpad.net/nova/+spec/user-locale-api

--

Thanks,

Matt

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-sigs] Dropping lazy translation support [ In reply to ]

doug at doughellmann

Nov 5, 2018, 11:36 AM

Post #2 of 7 (863 views)

Permalink

Matt Riedemann <mriedemos@gmail.com> writes:

> This is a follow up to a dev ML email [1] where I noticed that some
> implementations of the upgrade-checkers goal were failing because some
> projects still use the oslo_i18n.enable_lazy() hook for lazy log message
> translation (and maybe API responses?).
>
> The very old blueprints related to this can be found here [2][3][4].
>
> If memory serves me correctly from my time working at IBM on this, this
> was needed to:
>
> 1. Generate logs translated in other languages.
>
> 2. Return REST API responses if the "Accept-Language" header was used
> and a suitable translation existed for that language.
>
> #1 is a dead horse since I think at least the Ocata summit when we
> agreed to no longer translate logs since no one used them.
>
> #2 is probably something no one knows about. I can't find end-user
> documentation about it anywhere. It's not tested and therefore I have no
> idea if it actually works anymore.
>
> I would like to (1) deprecate the oslo_i18n.enable_lazy() function so
> new projects don't use it and (2) start removing the enable_lazy() usage
> from existing projects like keystone, glance and cinder.
>
> Are there any users, deployments or vendor distributions that still rely
> on this feature? If so, please speak up now.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2018-November/136285.html
> [2] https://blueprints.launchpad.net/oslo-incubator/+spec/i18n-messages
> [3] https://blueprints.launchpad.net/nova/+spec/i18n-messages
> [4] https://blueprints.launchpad.net/nova/+spec/user-locale-api
>
> --
>
> Thanks,
>
> Matt
>
> _______________________________________________
> openstack-sigs mailing list
> openstack-sigs@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs

I think the lazy stuff was all about the API responses. The log
translations worked a completely different way.

Doug

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-sigs] Dropping lazy translation support [ In reply to ]

mriedemos at gmail

Nov 5, 2018, 1:13 PM

Post #3 of 7 (863 views)

Permalink

On 11/5/2018 1:36 PM, Doug Hellmann wrote:
> I think the lazy stuff was all about the API responses. The log
> translations worked a completely different way.

Yeah maybe. And if so, I came across this in one of the blueprints:

https://etherpad.openstack.org/p/disable-lazy-translation

Which says that because of a critical bug, the lazy translation was
disabled in Havana to be fixed in Icehouse but I don't think that ever
happened before IBM developers dropped it upstream, which is further
justification for nuking this code from the various projects.

--

Thanks,

Matt

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-sigs] Dropping lazy translation support [ In reply to ]

doug at doughellmann

Nov 5, 2018, 1:36 PM

Post #4 of 7 (863 views)

Permalink

Matt Riedemann <mriedemos@gmail.com> writes:

> On 11/5/2018 1:36 PM, Doug Hellmann wrote:
>> I think the lazy stuff was all about the API responses. The log
>> translations worked a completely different way.
>
> Yeah maybe. And if so, I came across this in one of the blueprints:
>
> https://etherpad.openstack.org/p/disable-lazy-translation
>
> Which says that because of a critical bug, the lazy translation was
> disabled in Havana to be fixed in Icehouse but I don't think that ever
> happened before IBM developers dropped it upstream, which is further
> justification for nuking this code from the various projects.

I agree.

Doug

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-sigs] Dropping lazy translation support [ In reply to ]

openstack at nemebean

Nov 5, 2018, 1:39 PM

Post #5 of 7 (863 views)

Permalink

On 11/5/18 3:13 PM, Matt Riedemann wrote:
> On 11/5/2018 1:36 PM, Doug Hellmann wrote:
>> I think the lazy stuff was all about the API responses. The log
>> translations worked a completely different way.
>
> Yeah maybe. And if so, I came across this in one of the blueprints:
>
> https://etherpad.openstack.org/p/disable-lazy-translation
>
> Which says that because of a critical bug, the lazy translation was
> disabled in Havana to be fixed in Icehouse but I don't think that ever
> happened before IBM developers dropped it upstream, which is further
> justification for nuking this code from the various projects.
>

It was disabled last-minute, but I'm pretty sure it was turned back on
(hence why we're hitting issues today). I still see coercion code in
oslo.log that was added to fix the problem[1] (I think). I could be
wrong about that since this code has undergone significant changes over
the years, but it looks to me like we're still forcing things to be
unicode.[2]

1: https://review.openstack.org/#/c/49230/3/openstack/common/log.py
2:
https://github.com/openstack/oslo.log/blob/a9ba6c544cbbd4bd804dcd5e38d72106ea0b8b8f/oslo_log/formatters.py#L414

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [Openstack-sigs] Dropping lazy translation support [ In reply to ]

rochelle.grober at huawei

Nov 6, 2018, 3:24 PM

Post #6 of 7 (862 views)

Permalink

I seem to recall list discussion on this quite a ways back. I think most of it happened on the Docs ml, though. Maybe Juno/Kilo timeframe? If possible, it would be good to search over the code bases for places it was called to see its current footprint. I'm pretty sure it was the docs folks working with the oslo folks to make it work. But then the question was put to the ops folks about translations of logs (maybe the New York midcycle) and ops don't use translation. The ops input was broadcast to dev and docs and most efforts stopped at that point. But, I believe some projects had already done some work on lazy translation. I suspect the amount done, though was pretty low.

Maybe the fastest way to get info would be to turn it off and see where the code barfs in a long run (to catch as many projects as possible)?

--rocky

> From: Ben Nemec > Sent: Monday, November 05, 2018 1:40 PM
>
> On 11/5/18 3:13 PM, Matt Riedemann wrote:
> > On 11/5/2018 1:36 PM, Doug Hellmann wrote:
> >> I think the lazy stuff was all about the API responses. The log
> >> translations worked a completely different way.
> >
> > Yeah maybe. And if so, I came across this in one of the blueprints:
> >
> > https://etherpad.openstack.org/p/disable-lazy-translation
> >
> > Which says that because of a critical bug, the lazy translation was
> > disabled in Havana to be fixed in Icehouse but I don't think that ever
> > happened before IBM developers dropped it upstream, which is further
> > justification for nuking this code from the various projects.
> >
>
> It was disabled last-minute, but I'm pretty sure it was turned back on (hence
> why we're hitting issues today). I still see coercion code in oslo.log that was
> added to fix the problem[1] (I think). I could be wrong about that since this
> code has undergone significant changes over the years, but it looks to me like
> we're still forcing things to be unicode.[2]
>
> 1: https://review.openstack.org/#/c/49230/3/openstack/common/log.py
> 2:
> https://github.com/openstack/oslo.log/blob/a9ba6c544cbbd4bd804dcd5e38
> d72106ea0b8b8f/oslo_log/formatters.py#L414
>

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [Openstack-sigs] Dropping lazy translation support [ In reply to ]

mriedemos at gmail

Nov 6, 2018, 4:28 PM

Post #7 of 7 (861 views)

Permalink

On 11/6/2018 5:24 PM, Rochelle Grober wrote:
> Maybe the fastest way to get info would be to turn it off and see where the code barfs in a long run (to catch as many projects as possible)?

There is zero integration testing for lazy translation, so "turning it
off and seeing what breaks" wouldn't result in anything breaking.

--

Thanks,

Matt

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators