Open Stack

At the risk of getting defensive, I do want to make some points relating 
to Oslo specifically here.

TLDR at the bottom if your eyes glaze over at the wall of text.

On 4/6/20 3:10 AM, Dmitry Tantsur wrote:
> 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:

I think it's relevant to keep in mind that Oslo didn't start out as a 
collection of libraries, it started out as a bunch of code forklifted 
from Nova for use by other OpenStack services. It was a significant 
effort just to get the Nova-isms out of it, much less trying to sanitize 
everything OpenStack-specific.

I also don't think it's fair to characterize Oslo as only focused on 
OpenStack today. In reality, many of our new libraries since the initial 
incubator split have been general purpose as often as not. Where they 
haven't, it's things like oslo.limit that are explicitly dependent on an 
OpenStack service (Keystone in this case). We believe in being good OSS 
citizens as much as anyone else.

There's also a boil the ocean problem with trying to generalize every 
solution to every problem. It's a question we ask every time a new 
library is proposed, but in some cases it just doesn't make sense to 
write a library for an audience that may or may not exist. And in some 
cases when such an audience appears, we have refactored libraries to 
make them more general purpose, while often keeping an 
OpenStack-specific layer to ease integration with OpenStack services. 
See oslo.concurrency and fasteners.

In fact, that kind of split is a pretty common pattern, even in cases 
where the underlying library didn't originate in Oslo/OpenStack. Think 
sqlalchemy/oslo.db, dogpile/oslo.cache, kombu/oslo.messaging. A lot of 
Oslo is glue code to make it easier to use something in a common way 
across OpenStack services.

> 1) oslo.config is a fantastic piece of software that the whole python 
> world could benefit from. Same for oslo.service, probably.

oslo.config is an interesting case because there is definitely interest 
outside OpenStack thanks to things like the Castellan config backend, 
but as Doug mentioned oslo.config is heavily opinionated (global config 
object, anyone?) and that's an issue for a lot of people. I will also 
point out that the only oslo.* dependency that oslo.config has is 
oslo.i18n, which itself has no other oslo dependencies, so there's not 
much barrier to entry to using it standalone today.

I would not inflict oslo.service on anyone I liked. :-P

Seriously though, I would advocate for using cotyledon if you're looking 
for a general purpose service library. It's not eventlet-based and 
provides a lot of the functionality of oslo.service, at least as I 
understand it. It was also written by an ex-Oslo contributor outside of 
OpenStack so maybe it's an interesting case study for this discussion. I 
don't know how much contribution it gets from other sources, but that 
would be good to look into.

> 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.

oslo.concurrency has already been decomposed into general purpose code 
(fasteners) and OpenStack-specific, at least for the most part. I'm sure 
the split isn't perfect, but it's not like we haven't recognized the 
need for better concurrency libraries in Python as a whole. Note that 
fasteners also lives outside Oslo in another ex-Osloers personal repo. 
Again, I'm not sure whether that was beneficial or not but it might be 
worth reaching out to Mehdi and Josh to see how they feel about it.

I would probably -2 any attempt to split oslo.utils. You'd end up with a 
bunch of single file libraries and a metric ****-ton of administrative 
overhead. It's bad enough managing 40 some repos as it is. Also, that's 
another library with minimal cross-dependencies with the rest of Oslo 
(just oslo.i18n again), which was an intentional design decision to make 
it relatively painless to pull in.

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

oslo.log basically provides convenience functions for OpenStack 
services, which is kind of what the oslo.* libraries should do. It 
provides built-in support for things like context objects, which are 
fairly domain-specific and would be difficult to generalize. It also 
provides a common set of configuration options so each project doesn't 
have to write their own. We don't need 20 different ways to enable debug 
logging. :-)

oslo.i18n is mostly for lazy translation, which apparently is a thing 
people still use even though the company pushing for it in the first 
place no longer cares. We've also had calls to remove it completely 
because it's finicky and tends to break things if the consuming projects 
don't follow the best practices with translated strings. So it's in a 
weird limbo state.

I did talk with JP in Shanghai about possibly making it optional because 
it pulls in a fair amount of translation files which can bloat minimal 
containers. I looked into it briefly and I think it would be possible, 
although I don't remember a lot of details because nobody was really 
pushing for it anymore so it's hard to justify spending a bunch of time 
on it.

TLDR: I think Oslo provides value both in and out of OpenStack 
(shocking, I know!). I'm sure the separation isn't perfect, but what is?

There are some projects that have been split out of it that might be 
interesting case studies for this discussion if anyone wants to follow 
up. Not it. ;-)

-Ben