fix an incorrect behavior around the lock

[nraynaud]

• rebooting during an operation might lead the system to believe that said operation is still running.

[stormi]

For your next commit --amend:

• The first line should begin with a capital F
• The second line should remain empty and have the body only start on the third line
• Ideally, lines don't go beyond 70 chars

We formalized our commit message conventions at https://xcp-ng.org/docs/develprocess.html#commit-message-conventions

[stormi]

I'm sharing here the results of my "virtual" tests (I did not execute anything, I just followed the source code. Hopefully I did it right), as I did on mattermost.

Not giving up without trying to get the lock definitely seems the right move to me and should indeed solve the main issue.

In addition to the undefined attribute discussed above, I noted an unexpected change:

• When the attempted operation is update and the current operation is already update, it will likely wait for 10s instead of failing instantly as it did before. Ideally, we'd not wait for 10s here, as there's no reason to wait for the lock when an update is already in progress.

There's also a change that probably does not have any functional impact, but could probably be simplified:

• When the attempted operation is update and the current operation is something else (check_update), if the timeout is reached, the execution path is a bit complicated (OperationException is raised once with an uncomplete message, then catched, then raised again with a complete message). To be discussed: I think that _timeout_reached does not need to do anything anymore since the FileLockerError will be catched in OperationLocker._lock (and the timeout feature is used only in the updater plugin so this shouldn't break other plugins)

[Wescoeur]

* Ideally, we'd not wait for 10s here, as there's no reason to wait for the lock when an update is already in progress.

Not easy, because we take the lock before reading the state in this commit. And if we read before, we can have the bad behavior fixed by this same commit: the lock content can be invalid if the host has been rebooted.

[stormi]

If the host has rebooted, the contents is stale indeed but it won't matter as we will be able to get the lock.

[Wescoeur]

True, we use a non-blocking flag. :+1: We can execute a trylock, and then check the state, and then we can wait or raise.

[benjamreis]

Closing this: it has been solved in https://github.com/xcp-ng/xcp-ng-xapi-plugins/pull/31