<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 6, 2020, at 4:10 AM, Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com" class="">dtantsur@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="">Hi,<br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 3, 2020 at 9:35 AM Jean-Philippe Evrard <<a href="mailto:jean-philippe@evrard.me" class="">jean-philippe@evrard.me</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class=""></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class="">Also, how is the reliance on oslo a problem? Do you want to use another<br class="">library in the python ecosystem instead? If true, what about phasing<br class="">out that part of oslo, so we don't have to maintain it? Just curious.<span class="Apple-converted-space"> </span><br class=""></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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:<br class=""></div><div class="">1) oslo.config is a fantastic piece of software that the whole python world could benefit from. Same for oslo.service, probably.<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><div class="">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.<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><div class="">3) I'm genuinely not sure why oslo.log and oslo.i18n exist and which parts of their functionality cannot be moved upstream.<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div></div><br class=""><div class="">Doug</div><div class=""><br class=""></div></body></html>