Loading…
This event has ended. Create your own event → Check it out
This event has ended. Create your own
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.
View analytic
Wednesday, November 5 • 09:50 - 10:30
Resource locking in Ironic

Sign up or log in to save this to your schedule 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
Dufy Le Meridien

Attendees (30)