----- Original Message ----- > From: "Saggi Mizrahi" <smizr...@redhat.com> > To: "arch" <a...@ovirt.org> > Cc: "Nir Soffer" <nsof...@redhat.com>, "David Teigland" <teigl...@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 _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
