settingsLogin | Registersettings

[openstack-dev] [oslo] Can we stop global requirements update?

0 votes

Hoy,

So Gnocchi gate is all broken (agaiiiin) because it depends on "pbr" and
some new release of oslo.* depends on pbr!=2.1.0.

Neither Gnocchi nor Oslo cares about whatever bug there is in pbr 2.1.0
that got in banished by requirements Gods. It does not prevent it to be
used e.g. to install the software or get version information. But it
does break anything that is not in OpenStack because well, pip installs
the latest pbr (2.1.0) and then oslo.* is unhappy about it.

So I understand the culprit is probably pip installation scheme, and we
can blame him until we fix it. I'm also trying to push pbr 2.2.0 to
avoid the entire issue.

But for the future, could we stop updating the requirements in oslo libs
for no good reason? just because some random OpenStack project hit a bug
somewhere?

For example, I've removed requirements update on tooz¹ for more than a
year now, which did not break anything in the meantime, proving that
this process is giving more problem than solutions. Oslo libs doing that
automatic update introduce more pain for all consumers than anything (at
least not in OpenStack).

So if we care about Oslo users outside OpenStack, I beg us to stop this
crazyness. If we don't, we'll just spend time getting rid of Oslo over
the long term…

My 2c,

Cheers,

¹ Unless some API changed in a dep and we needed to raise the dep,
obviously.

--
Julien Danjou

Free Software hacker

https://julien.danjou.info


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

asked May 19, 2017 in openstack-dev by Julien_Danjou (20,500 points)   2 4 6

30 Responses

0 votes

On Thu, May 18 2017, Mike Bayer wrote:

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?

Yes, and many reviews around that. I'll let Mehdi comments if he feels
like it. :)

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.

I guess it depends what you mean by everyone. FTR, one of the two first
projects in OpenStack, Swift, never used anything from Oslo for anything
and always refused to depends on any of its library.

--
Julien Danjou
/* Free Software hacker
https://julien.danjou.info */


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded May 18, 2017 by Julien_Danjou (20,500 points)   2 4 6
0 votes

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.setwakeupfd), but oslo.service don't
use it. I have tried to run callbacks only on the main thread with
setwakeupfd, 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.

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.

--
Mehdi Abaakouk
mail: sileht@sileht.net
irc: sileht


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded May 19, 2017 by Mehdi_Abaakouk (4,040 points)   2 4
0 votes

On Fri, May 19 2017, Mehdi Abaakouk wrote:

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.

TBH Keystone get rid of it too. But they only provide WSGI servers. They
don't build any daemon so they don't need and user either Cotyledon nor
oslo.service. :)

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.

Cotyledon is explicitly better just by being out of Oslo, because it's
usable by the whole Python ecosystem. :)

--
Julien Danjou
-- Free Software hacker
-- https://julien.danjou.info


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded May 19, 2017 by Julien_Danjou (20,500 points)   2 4 6
0 votes

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.setwakeupfd), but oslo.service don't
use it. I have tried to run callbacks only on the main thread with
setwakeupfd, 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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 19, 2017 by Doug_Hellmann (87,520 points)   3 4 12
0 votes

Mehdi Abaakouk wrote:
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.

Octavia is using cotyledon and they have gotten rid of eventlet. Didn't
seem like it was that hard either to do it (of course the experience in
how easy it was is likely not transferable to other projects...)

-Josh


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 19, 2017 by harlowja_at_fastmail (16,200 points)   2 5 8
0 votes

On 05/19/2017 04:23 AM, Mehdi Abaakouk wrote:

And some applications rely

on implicit internal contract/behavior/assumption.

IMO that's a bug for them. I'm inspired to see that Keystone, Nova
etc. are able to move between and eventlet backend and a mod_wsgi
backend. IMO eventlet is really not needed for those services that
present a REST interface. Although for a message queue with lots of
long-running connections that receive events, that's a place where I
*would* want to use a polling / non-blocking model. But I'd use it
explicitly, not with monkeypatching.

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.

While I don't know the specifics for your project(s), I don't buy that
in general because IMO eventlet is not giving us any performance boost
in the majority of cases. most of our IO is blocking on the database
and all the applications have DB connections throttled at about 50 per
process at the max, and that's only recently, it used to be just 15.

Changing from oslo.service to cotyledon is
really easy on the side.

I'd ask why not oslo.cotyledon but it seems there's a faction here that
is overall moving out of the Openstack umbrella in any case.

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.

Many (most?) of the web services can run under mod_wsgi with threads,
Keystone seems to be standard on this now and I get the impression Nova
is going in that direction too. (anyone correct me if I'm wrong on
any of that, I looked to ask around on IRC but it's too late in the day).

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()'.

So, I've used gevent more than eventlet in my own upstream non-blocking
work, and while this opinion is like spilling water in the ocean, I
think applications should never use monkeypatching. They should call
into the eventlet/gevent greenlet API directly if that's what they want
to do.

Of course this means that database logic has to move out of greenlets
entirely since none of the DBAPIs use non-blocking IO. That's fine.
Database-oriented business logic should not be in greenlets. I've
written about this as well. If one is familiar enough with greenlets
and threads you can write an application that makes explicit use of
both. However, that's application level stuff. Web service apps like
Nova conductor / Neutron / Keystone should not be aware of any of that.
They should be coded to assume nothing about context switching. IMO
the threading model is "safer" to code towards since you have to handle
locking and concurrency contingencies explicitly without hardwiring that
to your assumptions about when context switching is to take place and
when it's not.

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.setwakeupfd), but oslo.service don't
use it. I have tried to run callbacks only on the main thread with
setwakeupfd, 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've no doubt oslo.service has major eventlet problems baked in, I've
looked at it a little bit but didn't go too far with it. That still
doesn't mean there shouldn't be an "oslo.service2" that can effectively
produce a concurrency-agnostic platform. It of course would have the
goal in mind of moving projects off eventlet since as I mentioned,
eventlet monkeypatching should not be used which means our services
should do most of their "implicitly concurrent" work within threads.

Basically I think openstack should be getting off eventlet in a big way
so I guess my sentiment here is that the Gnocchi / Cotyledon /etc.
faction is just splitting off rather than serving as any kind of
direction for the rest of Openstack to start looking. But that's only
an impression, maybe projects will use Cotyledon anyway. If every
project goes off and uses something completely different though, then I
think we're losing. The point of oslo was to prevent 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.

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.

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.

OK, so that would be your oslo.cotyledon. That works.

--
Mehdi Abaakouk
mail: sileht@sileht.net
irc: sileht


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 19, 2017 by Mike_Bayer (15,260 points)   1 5 6
0 votes

FTFY

On 05/19/2017 03:58 PM, Joshua Harlow wrote:
Mehdi Abaakouk wrote:

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.

Octavia is using cotyledon and they have gotten rid of eventlet. Didn't
seem like it was that hard either to do it (of course the experience in
how easy it was is likely not transferable to other projects...)

-Josh


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 19, 2017 by Mike_Bayer (15,260 points)   1 5 6
0 votes

On Fri, May 19 2017, Mike Bayer wrote:

IMO that's a bug for them.

Of course it's a bug. IIRC Mehdi tried to fix it without much success.

I'm inspired to see that Keystone, Nova etc. are
able to move between and eventlet backend and a mod_wsgi backend. IMO
eventlet is really not needed for those services that present a REST interface.
Although for a message queue with lots of long-running connections that receive
events, that's a place where I *would* want to use a polling / non-blocking
model. But I'd use it explicitly, not with monkeypatching.

+1

I'd ask why not oslo.cotyledon but it seems there's a faction here that is
overall moving out of the Openstack umbrella in any case.

Not oslo because it can be used by other projects than just OpenStack.
And it's a condition of success. As Mehdi said, Oslo has been deserted
in the recent cycles, so putting a lib there as very little chance of
seeing its community and maintenance help grow. Whereas trying to reach
the whole Python ecosystem is more likely to get traction.

As a maintainer of SQLAlchemy I'm surprised you even suggest that. Or do
you plan on doing oslo.sqlalchemy? ;)

Basically I think openstack should be getting off eventlet in a big way so I
guess my sentiment here is that the Gnocchi / Cotyledon /etc. faction is just
splitting off rather than serving as any kind of direction for the rest of
Openstack to start looking. But that's only an impression, maybe projects will
use Cotyledon anyway. If every project goes off and uses something completely
different though, then I think we're losing. The point of oslo was to prevent
that.

I understand your concern and opinion. I think you, me and Mehdi don't
have the experience as contributors in OpenStack. I invite you to try
moving any major OpenStack project to something like oslo.service2 or
Cotyledon or to achieve any technical debt resolution in OpenStack to
have a view on hard it is to tackle. Then you'll see where we stand. :)

Especially when your job is not doing that, but e.g. working on
Telemetry. :)

--
Julien Danjou
-- Free Software hacker
-- https://julien.danjou.info


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded May 20, 2017 by Julien_Danjou (20,500 points)   2 4 6
0 votes

On 05/20/2017 12:04 PM, Julien Danjou wrote:
On Fri, May 19 2017, Mike Bayer wrote:

IMO that's a bug for them.

Of course it's a bug. IIRC Mehdi tried to fix it without much success.

I'm inspired to see that Keystone, Nova etc. are
able to move between and eventlet backend and a mod_wsgi backend. IMO
eventlet is really not needed for those services that present a REST interface.
Although for a message queue with lots of long-running connections that receive
events, that's a place where I *would* want to use a polling / non-blocking
model. But I'd use it explicitly, not with monkeypatching.

+1

I'd ask why not oslo.cotyledon but it seems there's a faction here that is
overall moving out of the Openstack umbrella in any case.

Not oslo because it can be used by other projects than just OpenStack.
And it's a condition of success. As Mehdi said, Oslo has been deserted
in the recent cycles, so putting a lib there as very little chance of
seeing its community and maintenance help grow. Whereas trying to reach
the whole Python ecosystem is more likely to get traction.

As a maintainer of SQLAlchemy I'm surprised you even suggest that. Or do
you plan on doing oslo.sqlalchemy? ;)

I do oslo.db (which also is not "abandoned" in any way). the point of
oslo is that it is an openstack-centric mediation layer between some
common service/library and openstack.

it looks like there already is essentially such a layer for cotyledon.
I'd just name it "oslo.cotyledon" :) or oslo. something. We have a
moose. It's cool.

Basically I think openstack should be getting off eventlet in a big way so I
guess my sentiment here is that the Gnocchi / Cotyledon /etc. faction is just
splitting off rather than serving as any kind of direction for the rest of
Openstack to start looking. But that's only an impression, maybe projects will
use Cotyledon anyway. If every project goes off and uses something completely
different though, then I think we're losing. The point of oslo was to prevent
that.

I understand your concern and opinion. I think you, me and Mehdi don't
have the experience as contributors in OpenStack. I invite you to try
moving any major OpenStack project to something like oslo.service2 or
Cotyledon or to achieve any technical debt resolution in OpenStack to
have a view on hard it is to tackle. Then you'll see where we stand. :)

Sure, that's an area where I think the whole direction of openstack
would benefit from more centralized planning, but i have been here just
enough to observe that this kind of thing has been discussed before and
it is of course very tricky to implement.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 22, 2017 by Mike_Bayer (15,260 points)   1 5 6
0 votes

We discussed this for a long time, As I know , some projects use eventlet
heavily like Nova [1],
If everyon agree with removing eventlet , we can set it as one of comunnity
goals[2]

[1]https://github.com/openstack/nova/blob/master/doc/source/threading.rst
[2]https://etherpad.openstack.org/p/community-goals

2017-05-20 5:09 GMT+08:00 Mike Bayer mbayer@redhat.com:

FTFY

On 05/19/2017 03:58 PM, Joshua Harlow wrote:

Mehdi Abaakouk wrote:

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.

Octavia is using cotyledon and they have gotten rid of eventlet. Didn't
seem like it was that hard either to do it (of course the experience in how
easy it was is likely not transferable to other projects...)

-Josh



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
ChangBo Guo(gcb)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 22, 2017 by ChangBo_Guo (4,540 points)   4 6
...