[libvirt] [PATCH 3/3] sanlock: Properly init io_timeout

[John Ferlan]

On 09/15/2016 10:35 AM, Michal Privoznik wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1292984
> 
> Hold on to your hats, because this is gonna be wild.
> 
> In bd3e16a3 I've tried to expose sanlock io_timeout. What I had
> not realized (because there is like no documentation for sanlock
> at all) was very unusual way their APIs work. Basically, what we
> do currently is:
> 
>     sanlock_add_lockspace_timeout(&ls, io_timeout);
> 
> which adds a lockspace to sanlock daemon. One would expect that
> io_timeout sets the io_timeout for it. Nah! That's where you are
> completely off the tracks. It sets timeout for next lockspace you
> will probably add later. Therefore:
> 
>    sanlock_add_lockspace_timeout(&ls, io_timeout = 10);
>    /* adds new lockspace with default io_timeout */
> 
>    sanlock_add_lockspace_timeout(&ls, io_timeout = 20);
>    /* adds new lockspace with io_timeout = 10 */
> 
>    sanlock_add_lockspace_timeout(&ls, io_timeout = 40);
>    /* adds new lockspace with io_timeout = 20 */
> 
> And so on. You get the picture.
> Fortunately, we don't allow setting io_timeout per domain or per
> domain disk. So we just need to set the default used in the very
> first step and hope for the best (as all the io_timeout-s used
> later will have the same value).
> 
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> ---
>  src/locking/lock_driver_sanlock.c | 25 ++++++++++++++++++++++++-
>  1 file changed, 24 insertions(+), 1 deletion(-)
> 

Any thoughts about modifying src/locking/sanlock.conf in order add some
text there that indicates support for 'io_timeout' requires at least
sanlock 2.7 (or something similar).

Beyond that things seem reasonable to me

ACK

John