Open Stack

On 05/18/2017 02:37 PM, Julien Danjou wrote:
> On Thu, May 18 2017, Mike Bayer wrote:
> 
>> I'm not understanding this?  do you mean this?
> 
> In the long run, yes. Unfortunately, we're not happy with the way Oslo
> libraries are managed and too OpenStack centric. I've tried for the last
> couple of years to move things on, but it's barely possible to deprecate
> anything and contribute, so I feel it's safer to start fresh and better
> alternative. Cotyledon by Mehdi is a good example of what can be
> achieved.


here's cotyledon:

https://cotyledon.readthedocs.io/en/latest/


replaces oslo.service with a multiprocessing approach that doesn't use 
eventlet.  great!  any openstack service that rides on oslo.service 
would like to be able to transparently switch from eventlet to 
multiprocessing the same way they can more or less switch to mod_wsgi at 
the moment.    IMO this should be part of oslo.service itself.   Docs 
state: "oslo.service being impossible to fix and bringing an heavy 
dependency on eventlet, "  is there a discussion thread on that?

I'm finding it hard to believe that only a few years ago, everyone saw 
the wisdom of not re-implementing everything in their own projects and 
using a common layer like oslo, and already that whole situation is 
becoming forgotten - not just for consistency, but also when a bug is 
found, if fixed in oslo it gets fixed for everyone.

An increase in the scope of oslo is essential to dealing with the issue 
of "complexity" in openstack.  The state of openstack as dozens of 
individual software projects each with their own idiosyncratic quirks, 
CLIs, process and deployment models, and everything else that is visible 
to operators is ground zero for perceived operator complexity.



> 

> Though to comment on your example, oslo.db is probably the most useful
> Oslo library that Gnocchi depends on and that won't go away in a snap.
> :-(
>