On 07/10/2014 07:47 AM, Sean Dague wrote:
Honestly, that seems weird to me.
oslo.db is built as a common layer for OpenStack services.
eventlet is used by most OpenStack services.
There are lots of known issues with eventlet vs. our db access patterns.
Knowing that the db layer works in the c
Hello all.
After discussion in IRC, I agree, that we should take care about
interaction with eventlet at least because right now eventlet is the
OpenStack production configuration. So we must be sure, that we'll get no
issues, when we work with eventlet.
So I agree, that it makes a sense - to add
On 7/10/14, 7:47 AM, Sean Dague wrote:
> Honestly, that seems weird to me.
>
> oslo.db is built as a common layer for OpenStack services.
>
> eventlet is used by most OpenStack services.
>
> There are lots of known issues with eventlet vs. our db access patterns.
>
> Knowing that the db layer work
Honestly, that seems weird to me.
oslo.db is built as a common layer for OpenStack services.
eventlet is used by most OpenStack services.
There are lots of known issues with eventlet vs. our db access patterns.
Knowing that the db layer works in the common OpenStack pattern seems
really importa
Hello Angus!
IMO, the simple answer on your question is - tests for eventlet and oslo.db
interaction should be in the same place, where eventlet and oslo.db
interact. :)
A little digression - we suppose, that oslo.db should neither know, nor
take care whether target projects use eventlet/gevent/O
We have an issue with neutron (and presumably elsewhere), where mysqldb and
eventlet may deadlock, until the mysqldb deadlock timer fires.
I believe it's responsible for ~all of these failures:
http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkxvY2sgd2FpdCB0aW1lb3V0IGV4Y2VlZGVkOyB0cnkgcmVzdGFydGluZy
