<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 16, 2020 at 10:50 AM Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.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"><div dir="ltr"><div>Hi,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 15, 2020 at 9:55 PM Ben Nemec <<a href="mailto:openstack@nemebean.com" target="_blank">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"><br>
<br>
On 4/7/20 5:15 AM, Dmitry Tantsur wrote:<br>
> Hi,<br>
> <br>
> On Mon, Apr 6, 2020 at 11:06 PM Ben Nemec <<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a> <br>
> <mailto:<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>>> wrote:<br>
> <br>
>     At the risk of getting defensive, I do want to make some points<br>
>     relating<br>
>     to Oslo specifically here.<br></blockquote><div><snip> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
>      > 1) oslo.config is a fantastic piece of software that the whole<br>
>     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>
> <br>
> <br>
> oslo.config currently pulls in 16 dependencies to a clean venv, <br>
> including oslo.18n, Babel (why?) and requests (WHY?).<br>
<br>
Well, it's got translated strings and thus i18n, Babel is used for lazy <br>
translation, and requests is used for the remote file driver. It's <br>
posssible the latter two could/should be optional deps, but without them <br>
you do lose functionality.<br></blockquote><div><br></div><div>Please pardon my ignorance, it's the first time I hear about this driver? How many people are using it in the wild? Will it hurt much if we treat this dependencies similar to database/tooz backend, i.e. as optional?</div><div><br></div><div>More on Babel below.<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>
> <br>
> <br>
>     I would not inflict oslo.service on anyone I liked. :-P<br>
> <br>
> <br>
> So, you don't like us? :-P<br>
<br>
I don't _think_ I'm responsible for anyone using oslo.service. If I am, <br>
it happened years ago before I had dug into oslo.service much. ;-)<br>
<br>
> <br>
> <br>
>     Seriously though, I would advocate for using cotyledon if you're<br>
>     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<br>
>     discussion. I<br>
>     don't know how much contribution it gets from other sources, but that<br>
>     would be good to look into.<br>
> <br>
> <br>
> Good to know, thanks!<br>
> <br>
> <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<br>
>     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<br>
>     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>
> <br>
> <br>
> I *think* we mostly use oslo.concurrency for its execute() wrapper, <br>
> which seems like it could be a very useful library on its own (can I <br>
> suggest better-execute as a name?).<br>
<br>
Certainly something we could explore. Note that quite a few projects <br>
also use interprocess locks from o.c, in which case they're implicitly <br>
picking up some standard config opts for setting things like lock_path. <br>
I don't know if that's the case for Ironic though.<br></blockquote><div><br></div><div>We only use in-process locks.<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>
> <br>
> <br>
>     I would probably -2 any attempt to split oslo.utils. You'd end up<br>
>     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<br>
>     make<br>
>     it relatively painless to pull in.<br>
> <br>
> <br>
> I guess I have a personal dislike of libraries without a simple goal <br>
> (I've been also fighting with various "utils" modules inside Ironic - <br>
> with only limited luck).<br>
<br>
I guess I should have noted that I agree "utils" and "misc" modules tend <br>
to be a code smell, but in this case we had two bad options available <br>
and had to pick one. IMHO we've done a reasonable job of keeping <br>
oslo.utils pretty minimal, but obviously I'm a bit biased. :-)<br></blockquote><div><br></div><div>I guess I'm fine with that if we stop pulling in Babel :)</div><div><br></div><div>By the way, only oslo.i18n imports Babel directly. I'm proposing patches to various projects that move it out of requirements.txt. If you see one - please review.</div><div><br></div><div>E.g. a shameless ping for osc-lib folks: <a href="https://review.opendev.org/717737" target="_blank">https://review.opendev.org/717737</a></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>
> <br>
> I do suspect that at least some of oslo.utils contents could find a new <br>
> home, some maybe even in the stdlib. I also don't want us to end up in <br>
> the leafpad situation, on the other hand.<br>
<br>
That's entirely possible. We kind of lost our stdlib guy when Victor <br>
left the Oslo team so there may be things we've overlooked that could <br>
have been upstreamed.<br>
<br>
> <br>
> <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<br>
>     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<br>
>     projects<br>
>     don't follow the best practices with translated strings. So it's in a<br>
>     weird limbo state.<br>
> <br>
> <br>
> May I join these calls please? :) Will I break Zanata (assuming anybody <br>
> still translates ironic projects) if I switch to the upstream gettext?<br>
<br>
I don't think you'll break Zanata, I think you'll break anyone who was <br>
using lazy translation. I know there are users of it out there, but <br>
maybe we should look into getting a user survey question for Oslo that <br>
would give us an idea of how widely its used.<br></blockquote><div><br></div><div>I meant changing ironic, which honestly doesn't have real translations any more..<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>
> <br>
> <br>
>     I did talk with JP in Shanghai about possibly making it optional<br>
>     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>
> <br>
> <br>
> I'd be curious to hear more.<br>
<br>
Upon reflection, I think the thing we were looking to make optional was <br>
the Babel dep of oslo.i18n. It pulls in something like 6 MB of <br>
translation files </blockquote><div><br></div><div>Oh, yeah. When building our ramdisk, we have to manually delete these files to make it smaller.<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">and is only used to look up the available languages <br>
for lazy translation. I think code changes were needed though, it wasn't <br>
as simple as moving Babel to optional. There's probably an argument that <br>
we shouldn't be making that call when lazy translation is disabled <br>
anyway though.<br></blockquote><div><br></div><div>Is it something I can help with?</div><div><br></div><div>It seems that Babel is only used in get_available_languages. Can we make it an optional dependency for projects that do use this call (ironic does not)?</div></div></div></blockquote><div><br></div><div>I've prepared a patch: <a href="https://review.opendev.org/#/c/720404/">https://review.opendev.org/#/c/720404/</a> comments are welcome.<br></div><div>It seems that we need to update all projects using get_available_languages (mostly "core" projects) to depend on Babel explicity.</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"><div dir="ltr"><div class="gmail_quote"><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>
> <br>
> Dmitry<br>
> <br>
> <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>
<br>
</blockquote></div></div>
</blockquote></div></div>