Thanks, leyal. I've already changed the service framework from oslo.service to cotyledon https://review.openstack.org/#/c/530428/, and it works perfectly fine.
Cheers, Lingxian Kong (Larry) On Mon, Jan 8, 2018 at 2:47 AM, Eyal Leshem <ey.les...@gmail.com> wrote: > Hi Lingxian, > > I uploaded a patch for kuryr-kubernetes that monkey-patch the ThreadPool > with > GreenPool (https://review.openstack.org/#/c/530655/4/kuryr_kubernetes/ > thread_pool_patch.py). > > It's support only apply_async - but that should be enough for k8s. > > That can be dangers - if you use ThreadPool in other places in your code, > but in such case you can't run with eventlet anyway. > > hope that helps, > leyal > > > > > On 4 January 2018 at 23:45, Lingxian Kong <anlin.k...@gmail.com> wrote: > >> On Tue, Jan 2, 2018 at 1:56 AM, Eyal Leshem <ey.les...@gmail.com> wrote: >> >>> Hi , >>> >>> According to https://github.com/eventlet/eventlet/issues/147 - it's >>> looks that eventlet >>> has issue with "multiprocessing.pool". >>> >>> The ThreadPool used in code that auto-generated by swagger. >>> >>> Possible workaround for that is to monky-patch the client library , >>> and replace the pool with greenpool. >>> >> >> Hi, leyal, I'm not very familar with eventlet, but how can I monkey patch >> kubernetes python lib? >> The only way I can see now is to replace oslo.service with something >> else, e.g. cotyledon, avoid to use eventlet, that's a signaficant change >> though. I also found this bug https://bugs.launchpad.net >> /taskflow/+bug/1225275 in taskflow, they chose to not use >> multiprocessing module. >> >> Any other suggestions are welcomed! >> >> >>> >>> If someone has better workaround, please share that with us :) >>> >>> btw , I don't think that should be treated as compatibility issue >>> in the client python as it's an eventlet issue.. >>> >>> Thanks , >>> leyal >>> >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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
