<div dir="ltr"><div dir="ltr">Hi,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 6, 2020 at 11:06 PM Ben Nemec <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">At the risk of getting defensive, I do want to make some points relating <br>
to Oslo specifically here.<br></blockquote><div><br></div><div>I really do hope nothing I've said comes as offensive to the Oslo team. I'm not blaming you, we're all in this together :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
TLDR at the bottom if your eyes glaze over at the wall of text.<br>
<br>
On 4/6/20 3:10 AM, Dmitry Tantsur wrote:<br>
> With absolutely no disrespect meant to the awesome Oslo team, I think <br>
> the existence of Oslo libraries is a bad sign. I think as a strong FOSS <br>
> community we shouldn't invest into libraries that are either useful only <br>
> to us or at least are marketed this way. For example:<br>
<br>
I think it's relevant to keep in mind that Oslo didn't start out as a <br>
collection of libraries, it started out as a bunch of code forklifted <br>
from Nova for use by other OpenStack services. It was a significant <br>
effort just to get the Nova-isms out of it, much less trying to sanitize <br>
everything OpenStack-specific.<br>
<br>
I also don't think it's fair to characterize Oslo as only focused on <br>
OpenStack today. In reality, many of our new libraries since the initial <br>
incubator split have been general purpose as often as not. Where they <br>
haven't, it's things like oslo.limit that are explicitly dependent on an <br>
OpenStack service (Keystone in this case). We believe in being good OSS <br>
citizens as much as anyone else.<br>
<br>
There's also a boil the ocean problem with trying to generalize every <br>
solution to every problem. It's a question we ask every time a new <br>
library is proposed, but in some cases it just doesn't make sense to <br>
write a library for an audience that may or may not exist. And in some <br>
cases when such an audience appears, we have refactored libraries to <br>
make them more general purpose, while often keeping an <br>
OpenStack-specific layer to ease integration with OpenStack services. <br>
See oslo.concurrency and fasteners.<br>
<br>
In fact, that kind of split is a pretty common pattern, even in cases <br>
where the underlying library didn't originate in Oslo/OpenStack. Think <br>
sqlalchemy/oslo.db, dogpile/oslo.cache, kombu/oslo.messaging. A lot of <br>
Oslo is glue code to make it easier to use something in a common way <br>
across OpenStack services.<br>
<br>
> 1) oslo.config is a fantastic piece of software that the whole python <br>
> world could benefit from. Same for oslo.service, probably.<br>
<br>
oslo.config is an interesting case because there is definitely interest <br>
outside OpenStack thanks to things like the Castellan config backend, <br>
but as Doug mentioned oslo.config is heavily opinionated (global config <br>
object, anyone?) and that's an issue for a lot of people. I will also <br>
point out that the only oslo.* dependency that oslo.config has is <br>
oslo.i18n, which itself has no other oslo dependencies, so there's not <br>
much barrier to entry to using it standalone today.<br></blockquote><div><br></div><div>oslo.config currently pulls in 16 dependencies to a clean venv, including oslo.18n, Babel (why?) and requests (WHY?).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I would not inflict oslo.service on anyone I liked. :-P<br></blockquote><div><br></div><div>So, you don't like us? :-P<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Seriously though, I would advocate for using cotyledon if you're looking <br>
for a general purpose service library. It's not eventlet-based and <br>
provides a lot of the functionality of oslo.service, at least as I <br>
understand it. It was also written by an ex-Oslo contributor outside of <br>
OpenStack so maybe it's an interesting case study for this discussion. I <br>
don't know how much contribution it gets from other sources, but that <br>
would be good to look into.<br></blockquote><div><br></div><div>Good to know, thanks!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> 2) oslo.utils as a catch-all repository of utilities should IMO be <br>
> either moved to existing python projects or decomposed into small <br>
> generally reusable libraries (essentially, each sub-module could be a <br>
> library of its own). Same for oslo.concurrency.<br>
<br>
oslo.concurrency has already been decomposed into general purpose code <br>
(fasteners) and OpenStack-specific, at least for the most part. I'm sure <br>
the split isn't perfect, but it's not like we haven't recognized the <br>
need for better concurrency libraries in Python as a whole. Note that <br>
fasteners also lives outside Oslo in another ex-Osloers personal repo. <br>
Again, I'm not sure whether that was beneficial or not but it might be <br>
worth reaching out to Mehdi and Josh to see how they feel about it.<br></blockquote><div><br></div><div>I *think* we mostly use oslo.concurrency for its execute() wrapper, which seems like it could be a very useful library on its own (can I suggest better-execute as a name?).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I would probably -2 any attempt to split oslo.utils. You'd end up with a <br>
bunch of single file libraries and a metric ****-ton of administrative <br>
overhead. It's bad enough managing 40 some repos as it is. Also, that's <br>
another library with minimal cross-dependencies with the rest of Oslo <br>
(just oslo.i18n again), which was an intentional design decision to make <br>
it relatively painless to pull in.<br></blockquote><div><br></div><div>I guess I have a personal dislike of libraries without a simple goal (I've been also fighting with various "utils" modules inside Ironic - with only limited luck).</div><div><br></div><div>I do suspect that at least some of oslo.utils contents could find a new home, some maybe even in the stdlib. I also don't want us to end up in the leafpad situation, on the other hand.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> 3) I'm genuinely not sure why oslo.log and oslo.i18n exist and which <br>
> parts of their functionality cannot be moved upstream.<br>
<br>
oslo.log basically provides convenience functions for OpenStack <br>
services, which is kind of what the oslo.* libraries should do. It <br>
provides built-in support for things like context objects, which are <br>
fairly domain-specific and would be difficult to generalize. It also <br>
provides a common set of configuration options so each project doesn't <br>
have to write their own. We don't need 20 different ways to enable debug <br>
logging. :-)<br>
<br>
oslo.i18n is mostly for lazy translation, which apparently is a thing <br>
people still use even though the company pushing for it in the first <br>
place no longer cares. We've also had calls to remove it completely <br>
because it's finicky and tends to break things if the consuming projects <br>
don't follow the best practices with translated strings. So it's in a <br>
weird limbo state.<br></blockquote><div><br></div><div>May I join these calls please? :) Will I break Zanata (assuming anybody still translates ironic projects) if I switch to the upstream gettext?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I did talk with JP in Shanghai about possibly making it optional because <br>
it pulls in a fair amount of translation files which can bloat minimal <br>
containers. I looked into it briefly and I think it would be possible, <br>
although I don't remember a lot of details because nobody was really <br>
pushing for it anymore so it's hard to justify spending a bunch of time <br>
on it.<br></blockquote><div><br></div><div>I'd be curious to hear more.</div><div><br></div><div>Dmitry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
TLDR: I think Oslo provides value both in and out of OpenStack <br>
(shocking, I know!). I'm sure the separation isn't perfect, but what is?<br>
<br>
There are some projects that have been split out of it that might be <br>
interesting case studies for this discussion if anyone wants to follow <br>
up. Not it. ;-)<br>
<br>
-Ben<br>
<br>
</blockquote></div></div>