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