Ocfs2 devel - Oct 2013 - [PATCH 0/6] nocontrold: Eliminating ocfs2_controld v4

Hi,

This is an effort of removing ocfs2_controld.pcmk and getting ocfs2 DLM
handling up to the times with respect to DLM (>=4.0.1) and corosync
(2.3.x). AFAIK, cman also is being phased out for a unified corosync
cluster stack.

fs/dlm performs all the functions with respect to fencing and node
management and provides the API's to do so for ocfs2. For all future
references, DLM stands for fs/dlm code.

The advantages are:
 + No need to run an additional userspace daemon (ocfs2_controld)
 + No contrrold devince handling and controld protocol
 + Shifting responsibilities of node management to DLM layer

For backward compatibility, we are keeping the controld handling code. Once
enough time has passed we can remove a significant portion of the code.

This feature requires modification in the userspace ocfs2-tools.
The changes can be found at:
https://github.com/goldwynr/ocfs2-tools branch: nocontrold
Currently, not many checks are present in the userspace code,
but that would change soon.

These changes were developed on linux-stable 3.11.y. However, the 
changes are applicable to the current upstream as well. If you wish
to give the entire kernel a spin, the link is:

https://github.com/goldwynr/linux-stable branch: nocontrold

Changes since v3:
* Added version negotiation using DLM lock
* Used strlcpy() instead of memcpy()

Changes since v2:
* Joel's comments: patch re-factoring

Changes since v1:
* Backward compatibility with ocfs2_controld

-- 
Goldwyn

On Fri, 18 Oct 2013 09:44:54 -0500 Goldwyn Rodrigues <rgoldwyn at suse.de>
wrote:
> This is an effort of removing ocfs2_controld.pcmk and getting ocfs2 DLM
> handling up to the times with respect to DLM (>=4.0.1) and corosync
> (2.3.x). AFAIK, cman also is being phased out for a unified corosync
> cluster stack.
> 
> fs/dlm performs all the functions with respect to fencing and node
> management and provides the API's to do so for ocfs2. For all future
> references, DLM stands for fs/dlm code.
> 
> The advantages are:
>  + No need to run an additional userspace daemon (ocfs2_controld)
>  + No contrrold devince handling and controld protocol
>  + Shifting responsibilities of node management to DLM layer
> 
> For backward compatibility, we are keeping the controld handling code. Once
> enough time has passed we can remove a significant portion of the code.
> 
> This feature requires modification in the userspace ocfs2-tools.
> The changes can be found at:
> https://github.com/goldwynr/ocfs2-tools branch: nocontrold
> Currently, not many checks are present in the userspace code,
> but that would change soon.
> 
> These changes were developed on linux-stable 3.11.y. However, the 
> changes are applicable to the current upstream as well. If you wish
> to give the entire kernel a spin, the link is:
> 
> https://github.com/goldwynr/linux-stable branch: nocontrold
I queued this up so it will get some linux-next exposure when Stephen
gets back to his desk.  But I don't feel I can take it further without
suitable input from the other ocfs2 developers (please).

On Fri, Oct 18, 2013 at 09:44:54AM -0500, Goldwyn Rodrigues
wrote:
> Hi,
> 
> This is an effort of removing ocfs2_controld.pcmk and getting ocfs2 DLM
> handling up to the times with respect to DLM (>=4.0.1) and corosync
> (2.3.x). AFAIK, cman also is being phased out for a unified corosync
> cluster stack.
Thanks again for doing this work. I'm about halfway done with the patches
when I write this but things seem to be coming along well.

> fs/dlm performs all the functions with respect to fencing and node
> management and provides the API's to do so for ocfs2. For all future
> references, DLM stands for fs/dlm code.
> 
> The advantages are:
>  + No need to run an additional userspace daemon (ocfs2_controld)
>  + No contrrold devince handling and controld protocol
>  + Shifting responsibilities of node management to DLM layer
> 
> For backward compatibility, we are keeping the controld handling code. Once
> enough time has passed we can remove a significant portion of the code.
Can you give us some brief details on how backwards compatibility was
tested? I have a feeling that it would alleviate some concerns we had about
that when the 1st series hit ocfs2-devel.
	--Mark

--
Mark Fasheh