Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Sat, Sep 12, 2015 at 02:01:52PM +0200, Dietmar Maurer wrote:
> > In your case you should make use of the new 'set_cluster_config' API
> > call which takes a dictionary as its input. If you just want to set a
> > new storage plugin (but do not want to configure the plugin itself,
> > because the defaults are okay), your configuration dictionary should
> > look like this:
> >
> > {
> > 'nodes': [{'storage-plugin': 'drbdmanage.storage.lvm_thinlv.LvmThinLV',
> > 'name': 'YOURNODENAME'}],
> > 'globals': [{}], 'type': [{'type': 'node'}],
> > 'sites': [], 'plugins': []
> > }
>
> Really? The old approach works out of box, without any user intervention.
> And now I need to tell users to run such complex setup command?
Yes, because the other approach does not scale.
One of the reasons we develop drbdmanage is to avoid that users have to
copy drbd.conf files in their multi-node cluster (think of 20 nodes, or
100). And now users have to copy around drbdmanage.conf files to 100
nodes? Per plugin? And they have to keep track what configuration file
they currently have on every node? -> NO way. That information has to be
stored in the drbdmanage control volume, cluster wide, and not in a text
file per node.
That is the API for you as developer, not for a "user" like an admin.
The admin has a nice 'drbdmanage modify-config' command that then sets up his
configuration in the whole cluster. A developer should be able to handle
an API call.
>
> Any other idea how to set the default storage plugin? I compile and roll out
> my own packages, so I can modify the source code - but where is the best place?
There is no best place other than storing this kind of information
cluster wide. Again, for you as developer, and only if the default
configuration does not fit you needs (e.g., non-default storage plugin),
it is a _single_ API call.
Regards, rck