----- Original Message -----

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