Setting up CTDB on OCFS2 and VMs ...

[Rowland Penny]

On 01/01/15 18:53, Michael Adam wrote:
> On 2014-12-31 at 23:06 +0000, Rowland Penny wrote:
>> On 31/12/14 22:34, Martin Schwenke wrote:
>>> On Wed, 31 Dec 2014 15:46:30 +0000, Rowland Penny
>>> <repenny241155 at gmail.com> wrote:
>>>
>>>> Why have very similar data in 3 places ? why have the conf (which
>>>> incidentaly isn't called a conf file) in a different place from the
>>>> other ctdb files in /etc ?
>>> Everything should be in /var/lib/ctdb/.
>>>
>>> /var/lib/lib/ctdb/ is due to the Debian packaging bug that has already
>>> been discussed.  This is not CTDB's fault.
>> OK, I can accept that
>>> /var/ctdb/ is an old location that we still support as a fallback.
>>> Unfortunately, until the daemon gets to a particular point
>>> where /var/lib/ctdb/ is created, CTDB attempts to maintain backward
>>> compatibility by using /var/ctdb/.  That's clearly something we need to
>>> clean up.  However, it is superficial.
>> This, in my opinion, is stupid, shouldn't the daemon check/create
>> /var/lib/ctdb at the start, it is not superficial, it is spraying the HD
>> with totally unrequired directories and files.
>>
>>> I don't think that makes CTDB a *MESS*.  I think it means that CTDB has
>>> a superficial bug.  You're basing most of your evaluation on a Debian
>>> packaging bug that we discussed weeks ago.  :-(
>> I hit another problem, that, until Michael Adam posted, I was unaware of, It
>> seems that ctdb is hardcoded to put the socket in /var/lib/run/ctdb.
> There is of course a hard-coded *default* in ctdb. And this is
> usually /var/run/ctdb/ctdbd.socket. Of course packagers can change
> that hard coding of the default to another value.
> And it has by accident been changed to var/lib/run... in the
> debian packages. See the bug report martin posted:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773016

Why not just do it like samba & smb.conf, it is set at compile time but 
can also be changed at ctdb startup by using -s /path/to/smb.conf

>
>> I cannot find any documentation to tell me this (note I am not saying it
>> doesn't exist, just that I cannot find it).
> Look for socket in "man ctdbd.conf"

OK, will do.

>> changing the line in smb.conf to
>> point to the hardcoded socket, allows samba to join the domain and
>> subsequently samba to start,
> That is just a band aid for bad packaging.
> If you compile samba against the proper ctdb,
> this setting is not needed.
> The smb.conf setting is also useful in case
> you choose (as the admin of the cluster) to chang
> ctdb's socket location by the CTDB_SOCKET variable.
>
>> but I still do not have a lock on ctdb, if I
>> set the lockfile location in /etc/default/ctdb, ctdb mostly refuses to start
>> and when it does start, there is only one healthy node.
>> Now I don't know whose fault this is, debian or ctdb, but you seem to know
>> that there are problems and seem to be pointing the finger at debian and
>> seem to be asking me to help fix it by reporting bugs to debian. Well, it is
>> your software, so it is your responsibility to get it fixed.
> You misunderstand: If there is a problem inside ctdb proper,
> this is ours to fix, and Martin certainly did not suggest to
> report propoer ctdb bugs to debian packaging! But if the packaging
> adds a problem, that is beyond our reach. And someone should report
> that to the debian folks, ideally someone who has experienced
> the problem himself. :) As you can see, Martin himself has
> already reported several bugs to debian packaging...

I will look into the bug reports

> And regarding your reclock problem:
> As indicated earlier, I am inclined to think that
> this is a problem with your CusterFs-Setup or ctdb's
> configuration. We need more details here.

I have posted how I set up the cluster, if you want to know anything 
else, just ask.

Rowland

> Michael
>