Excerpts from Mehdi Abaakouk's message of 2017-05-19 10:23:09 +0200: > On Thu, May 18, 2017 at 03:16:20PM -0400, Mike Bayer wrote: > > > > > >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. > > I have quickly presented cotyledon some summit ago, we said we will wait > to see if other projects want to get rid of eventlet before adopting > such new lib (or merge it with oslo.service). > > But for now, the lib is still under telemetry umbrella. > > Keeping the current API and supporting both are (I think) impossible. > The current API is too eventlet centric. And some applications rely > on implicit internal contract/behavior/assumption. > > Dealing about concurrent/thread/signal safety in multithreading app or > eventlet app is already hard enough. So having the lib that deals with > both is even harder. We already have oslo.messaging that deals with > 3 threads models, this is just an unending story of race conditions. > > Since a new API is needed, why not writing a new lib. Anyways when you > get rid of eventlet you have so many thing to change to ensure your > performance will not drop. Changing from oslo.service to cotyledon is > really easy on the side. > > >Docs state: "oslo.service being impossible to fix and bringing an > >heavy dependency on eventlet, " is there a discussion thread on that? > > Not really, I just put some comments on reviews and discus this on IRC. > Since nobody except Telemetry have expressed/try to get rid of eventlet. > > For the story we first get rid of eventlet in Telemetry, fixes couple of > performance issue due to using threading/process instead > greenlet/greenthread. > > Then we fall into some weird issue due to oslo.service internal > implementation. Process not exiting properly, signals not received, > deadlock when signal are received, unkillable process, > tooz/oslo.messaging heartbeat not scheduled correctly, worker not > restarted when they are dead. All of what we expect from oslo.service > was not working correctly anymore because we remove the line > 'eventlet.monkeypatch()'. > > For example, when oslo.service receive a signal, it can arrive on any > thread, this thread is paused, the callback is run in this thread > context, but if the callback try to discus to your code in this thread, > the process lockup, because your code is paused. Python > offers tool to avoid that (signal.set_wakeup_fd), but oslo.service don't > use it. I have tried to run callbacks only on the main thread with > set_wakeup_fd, to avoid this kind of issue but I fail. The whole > oslo.service code is clearly not designed to be threadsafe/signalsafe. > Well, it works for eventlet because you have only one real thread. > > And this is just one example on complicated thing I have tried to fix, > before starting cotyledon. > > >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. > > Because the internal of cotyledon and oslo.service are so different. > Having the code in oslo or not doesn't help for maintenance anymore. > Cotyledon is a lib, code and bugs :) can already be shared between > projects that doesn't want eventlet.
Yes, I remember discussing this some time ago and I agree that starting a new library was the right approach. The changes needed to make oslo.service work without eventlet are too big, and rather than have 2 separate implementations in the same library a second library makes sense. > >An increase in the scope of oslo is essential to dealing with the > >issue of "complexity" in openstack. > > Increasing the scope of oslo works only if libs have maintainers. But > most of them lack of people today. Most of oslo libs are in maintenance > mode. But that another subject. > > > 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. > > Cotyledon have been written to be Openstack agnostic. But I have also > write an optional module within the library to glue oslo.config and > cotyledon. Mainly to mimic the oslo.config options/reload of > oslo.service and make operators experience unchanged for Openstack > people. That sounds like a good approach. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev