Re: [Openstack-operators] [openstack-dev] [Openstack-sigs] Dropping lazy translation support
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
Re: [Openstack-operators] [openstack-dev] [Openstack-sigs] Dropping lazy translation support
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
[Openstack-operators] no formal ops meetups team meeting today
Hello Ops, It appears there will not be enough attendance on IRC today for a useful ops meetups team meeting. I think everyone is getting ready for berlin next week, which at this stage is likely a better use of the time. We'll try to find a good venue for a social get-together on the Tuesday, which will be communicated nearer the time on the IRC channel and via email. Otherwise we will see you at the Forum! Chris -- Chris Morgan ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] FIPS Compliance
Sean McGinnis writes: > I'm interested in some feedback from the community, particularly those running > OpenStack deployments, as to whether FIPS compliance [0][1] is something folks > are looking for. > > I've been seeing small changes starting to be proposed here and there for > things like MD5 usage related to its incompatibility to FIPS mode. But looking > across a wider stripe of our repos, it appears like it would be a wider effort > to be able to get all OpenStack services compatible with FIPS mode. > > This should be a fairly easy thing to test, but before we put in much effort > into updating code and figuring out testing, I'd like to see some input on > whether something like this is needed. > > Thanks for any input on this. > > Sean > > [0] https://en.wikipedia.org/wiki/FIPS_140-2 > [1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators I know we've had some interest in it at different times. I think some of the changes will end up being backwards-incompatible, so we may need a "FIPS-mode" configuration flag for those, but in other places we could just switch hashing algorithms and be fine. I'm not sure if anyone has put together the details of what would be needed to update each project, but this feels like it could be a candidate for a goal for a future cycle once we have that information and can assess the level of effort. Doug ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
