[openstack-dev] [Ironic] What to do with reservation check in node update API?
dtantsur at redhat.com
Tue Jul 21 13:08:51 UTC 2015
On 07/21/2015 02:24 PM, Dmitry Tantsur wrote:
> Hi folks!
> If you're not aware already, I'm working on solving "node is locked"
> problems breaking users (and tracking it at
> https://etherpad.openstack.org/p/ironic-locking-reform). We have retries
> in place in client, but we all agree that it's not the eventual solution.
> One of the things we've figured out is that we actually have server-side
> retries - in task_manager.acquire. They're nice and configurable. Alas,
> we have one place that checks reservations without task_manager:
> (note that this check is actually racy)
> I'd like to ask your opinions on how to solve it? I have 3 ideas:
> 1. Just implement retries on API level (possibly split away a common
> function from task_manager).
> 2. Move update to conductor instead of doing it directly in API.
> 3. Don't check reservation when updating node. At all.
Another question folks: while the problem above is valid and should be
solved, I was actually keeping in mind another one:
This is also not retried, and it prevents updating during power
operations, which I'm not sure is a correct thing to do. WDYT about
And with check on provision state, the options are the same 1,2,3 as
above: move to conductor, reimplement retries, just ignore.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev