[openstack-dev] [cinder] cinder is broken until someone fixes the forking code
mbayer at redhat.com
Wed Mar 11 18:29:45 UTC 2015
Joshua Harlow <harlowja at outlook.com> wrote:
> I've also got the following up:
> Which tries the force file descriptors to be closed; although I'm unsure where the tempest results went (and am rechecking that); maybe it breaks so badly that tempest doesn't even run?
OK, I guess if the descriptors are closed then the pool, because we have a
lot of reconnection stuff set up in oslo.db, will figure it out, catch the
error, and try again, without actually propagating the error. So it would
sort of “fix” the problem, rather than fail hard. But Cinder should really
at least prevent against this whole condition from occurring anyway.
> Mike Bayer wrote:
>> Hello Cinder -
>> I’d like to note that for issue
>> https://bugs.launchpad.net/oslo.db/+bug/1417018, no solution that actually
>> solves the problem for Cinder is scheduled to be committed anywhere. The
>> patch I proposed for oslo.db is on hold, and the patch proposed for
>> oslo.incubator in the service code will not fix this issue for Cinder, it
>> will only make it fail harder and faster.
>> I’ve taken myself off as the assignee on this issue, as someone on the
>> Cinder team should really propose the best fix of all which is to call
>> engine.dispose() when first entering a new child fork. Related issues are
>> already being reported, such as
>> https://bugs.launchpad.net/cinder/+bug/1430859. Right now Cinder is very
>> unreliable on startup and this should be considered a critical issue.
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev