----- Original Message -----
> From: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> To: "arch" <arch(a)ovirt.org>
> Cc: "Nir Soffer" <nsoffer(a)redhat.com>, "David Teigland" <teigland(a)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
