Loading…
OpenStack Kilo Design Summit has ended
This is the schedule for the Kilo Design Summit, where OpenStack contributors discuss the future of OpenStack development.
Click here for the main OpenStack Summit conference schedule.
Wednesday, November 5 • 09:50 - 10:30
Resource locking in Ironic

Sign up or log in to save this to your schedule, view media, leave feedback and see who's attending!

I wrote the TaskManager module to protect hardware operations from interruption in a distributed environment, but it's not perfect. A crashed Conductor can leave dangling locks that still require manual intervention to free; we haven't added automatic expiration to locks because some operations rightfully take a long time. Meanwhile, client requests get refused when a node is locked, regardless of what operation holds the lock. Even internal periodic jobs like sync_power_state take a lock, which can result in users getting unexpected NodeLocked errors.

Have we gone too far away from the original intent? Are we using locks too broadly, or do we need more fine-grained lock handling (types or reasons or duration-based locks)? Or should we simply make it easier for operators to manually release a lock, eg. by adding a REST verb to "unlock" a node?


Wednesday November 5, 2014 09:50 - 10:30 CET
Dufy Le Meridien

Attendees (0)