[PATCH] Change CTDB to use a Samba-style configuration file

[David Disseldorp]

Hi Martin,

On Tue, 17 Jul 2018 20:24:20 +1000, Martin Schwenke via samba-technical wrote:

> On Tue, 17 Jul 2018 11:56:48 +0200, David Disseldorp via
> samba-technical <samba-technical at lists.samba.org> wrote:
...
> > Looks like this flew under my radar, but just thought I'd mention that
> > it breaks the Linux-HA CTDB resource agent, which makes heavy use of
> > ctdbd command line parameters:
> > https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/CTDB#L624
> > 
> > I guess it should be possible to have the resource agent generate a
> > runtime ctdb configuration file, but it'll likely cause quite some
> > headaches WRT multi-version support.  
> 
> Hopefully we can work together to come up with a simple solution.
> 
> I notice that there's already a function called
> generate_ctdb_sysconfig().  I suggest 2 initial changes there, for
> versions Samba <=4.8:
> 
> 1. Change it to generate /etc/ctdb/ctdbd.conf or similar
> 
>    We tried to move the general CTDB config to that file from the
>    distro-specific files several years ago but not many people listened.
> 
> 2. Switch the daemon options to be config file options in the above file
> 
>    ctdbd.conf(5) will tell you the config file options and the daemon
>    options that they map to.  If you can get rid of the daemon options
>    then the work needed for Samba >=4.9 becomes much clearer.
> 
> Then you could have that function alternatively generate the
> new /etc/ctdb/ctdb.conf.

Sounds reasonable, thanks. I'll get started on this.

> The decision about which configuration file to generate could depend on
> the output of "ctdbd --help".  I've seen that sort of thing done before
> for other software.

There's already a version check to handle the logfile -> logging change,
so we could also piggy back on top of that:
https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/CTDB#L590

> There'll be a script out soon to generate a new configuration from an
> old one.

> Others can judge the robustness of this and make
> suggestions to improve it.  However, I'm trying to make it as complete
> as possible. I wouldn't suggest using it for this particular case... but
> it might provide some hints for updating generate_ctdb_sysconfig().
> 
> Sorry to cause pain but we're confident that this will be much better
> in the long term...

No worries. If ctdb becomes easier to maintain as a result of these
changes then I'm all for them, was just caught a little off guard in
this case.

Cheers, David