Open Stack

> On Apr 6, 2020, at 4:10 AM, Dmitry Tantsur <dtantsur at redhat.com> wrote:
> 
> Hi,
> 
> On Fri, Apr 3, 2020 at 9:35 AM Jean-Philippe Evrard <jean-philippe at evrard.me <mailto:jean-philippe at evrard.me>> wrote:
> 
> 
> Also, how is the reliance on oslo a problem? Do you want to use another
> library in the python ecosystem instead? If true, what about phasing
> out that part of oslo, so we don't have to maintain it? Just curious. 
> 
> The problem is that oslo libraries are OpenStack-specific. Imagine metal3, for example. When building our images, we can pull (most of) regular Python packages from the base OS, but everything with "oslo" in its name is on us. It's a maintenance burden.
> 
> With absolutely no disrespect meant to the awesome Oslo team, I think the existence of Oslo libraries is a bad sign. I think as a strong FOSS community we shouldn't invest into libraries that are either useful only to us or at least are marketed this way. For example:
> 1) oslo.config is a fantastic piece of software that the whole python world could benefit from. Same for oslo.service, probably.

I would love to have oslo.config more widely adopted outside of OpenStack. At the same time, it has a very opinionated way of managing config than most applications need, so I can understand why it might not be.

> 2) oslo.utils as a catch-all repository of utilities should IMO be either moved to existing python projects or decomposed into small generally reusable libraries (essentially, each sub-module could be a library of its own). Same for oslo.concurrency.

When I did the original analysis for breaking oslo-incubator up into separate libraries, I had to balance the work to create and manage individual libraries and their cross-dependencies with the desire to have everything nice and neat. The utils library ended up as a catch all for things that didn’t seem reusable outside of OpenStack so that at a time before all of our release automation was in place the team only had to manage ~30 libraries instead of ~50. Of course that can evolve, if someone feels strongly enough to do the work. It’s certainly easier today than it was back then.

> 3) I'm genuinely not sure why oslo.log and oslo.i18n exist and which parts of their functionality cannot be moved upstream.

The log library is there to make it simple for all OpenStack services to configure their logging in the same way. It’s glue between oslo.config and Python’s logging module. Similarly, the i18n library is the glue between oslo.config and Python’s gettext module.

The hint is in their names. The “oslo" prefix was reserved for libraries that are more likely to be seen as only useful within OpenStack. In a project as large as OpenStack, there’s a fair amount of code that can be reused but that wouldn’t make sense for use in any other code bases. For libraries that we thought would be useful by other communities, we chose more generic names.

Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200406/096b7fe7/attachment.html>