[ovirt-devel] Sanlock fencing reservations

[Nir Soffer]

----- Original Message -----
> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> To: "arch" <arch at ovirt.org>
> Cc: "Nir Soffer" <nsoffer at redhat.com>, "David Teigland" <teigland at redhat.com>
> Sent: Wednesday, February 26, 2014 6:14:33 PM
> Subject: Sanlock fencing reservations
> 
> I've recently been introduced to the this feature and I was wondering is this
> really
> the correct way to go for solving this particular problem.
> 
> My main issue is with making two unrelated flow dependent.

Hi Saggi,

Sorry for the late response.

The flows are related - sanlock already fencing as part of the lease and
resources keeping.

> By pushing this into the existing sanlock data structures you limit yourself
> in the future from changing either to optimize or even solve problems for a
> single use case.

I agree, we have 196 unused bits in the sanlock lease, which can be used
for other needs if we don't used them the new host_message api. We can 
keep the extra space forever - or use it now.

> 
> Having an independent daemon to perform this task will give more room as to
> how to implement the feature.

I agree, but we are not designing this system from scratch, and adding this
feature to the existing daemon is easy and makes sense. I thinks this is 
a good trade-off.

> 
> I don't want to reach a situation where we need to change a sanlock struct
> and not be able to do it as it makes problems with fencing flows.

This is the price for choosing this way.

> 
> I believe in the mantra that things should do one thing and do it well.
> This feels like an ad-hoc solution to a very niche problem.
> 
> 
> Further more, it kind of seems like a mailbox issue.
> Leaving a fencing request is just a message. In the
> future I can see it just being a suspend-to-disk request
> so that you don't even have to fence the host in such cases.
> 
> The only reason I see people putting it to sanlock is
> that it's a daemon that reads from disk and has does fencing.
> 
> I agree that in VDSMs current state putting this in the mailbox
> is unreliable to say the least but it doesn't mean that we can't
> have a small independent daemon to do the task until we get
> messaging in VDSM to a stable state.
> 
> IMHO it's better than having it as and ad-hoc feature to sanlock.
> A feature which we can't remove later as someone might depend on it.
> A feature that might limit us or that we might even abandon once we
> have more reliable disk based messaging in VDSM.
> 

I don't think we need another daemon that duplicate most of what sanlock
is doing now, and I would not mix critical messages (fencing) with everyday
messages in such new messaging solution.

Regards,
Nir