On Tue, Dec 20, 2016 at 02:56:51AM +0100, Jean-Marc Saffroy wrote: > Ah, so that could be a serious problem for me. I hoped to be able to use > dlm across distributions without having to qualify each possible > combination... > > > Within the context of one distribution things shouldn't break if the > > distribution is doing it's job. > > Does that mean that, for example, I could expect dlm instances in RHEL6 > and RHEL7 kernels to work together? I'm not sure you're talking to the right person any more. In the history of dlm in RHEL, the userland bits have usually only worked together within one major release. > How could instances of dlm_controld interact badly? I thought they were > just glue between dlm and corosync, and never directly talk on the > network. Do they have network-visible side effects on dlm/corosync? dlm_controld instances communicate using a protocol that could change. This is for coordinating lockspace recovery, not performing locking. > In the end, I need to work across distributions and their kernels, but I > could build from source a specific version of corosync and (the userland > part of) dlm. I expect that the kernel interface to dlm is stable > (right?), right > so the biggest risk would be incompatibilities in the dlm > protocol on the network. Is this protocol stable? With git I see that > DLM_HEADER_MAJOR/MINOR macros changed very rarely in recent years but I > can't tell if this is a good indicator. It's quite stable. Your situation sounds very unique. If you can choose and build userspace code yourself, they you don't need to worry about distributions I guess. Dave -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
