drbdmanage installation HowTo
==============================================================================


INSTALLATION
------------------------------------------------------------------------------

Prerequisites:
    DRBD 9 installed
    LVM installed
    python-dbus, python-gobject installed

IMPORTANT NOTICE:
The node names you enter must match the output of the "uname -n" command.

Installation procedure (all nodes):
    *  Install the drbdmanage package:
    *  Create a VG named drbdpool

Cluster initialization (first drbdmanage cluster node only):
    *  On the first node, issue the following command to initialize a new
       drbdmanage cluster:
         drbdmanage init <ipaddress>
       ... where <ipaddress> is the IP address of the network interface that
           DRBD should use to communicate with other nodes in the cluster

Adding nodes to a drbdmanage cluster:
    *  On a node of the existing drbdmanage cluster, issue the following
       command to prepare the cluster for integrating a new node:
         drbdmanage new-node <nodename> <ipaddress>
       ... where <nodename> is the node name of the node, and <ipaddress>
           is the IP address of the node that will join the cluster
       This command will also try to connect to the new node via ssh and
		 automatically join the cluster.
	 * If automatically joining is not possible: On the new node (the one that
		should join the cluster), enter the join command that you have
		received from the drbdmanage new-node command in the previous step (e.g., copy
		& paste)


CONFIGURATION
------------------------------------------------------------------------------

If you want to customize the settings of your drbdmanage server, you can
change its configuration by using 'drbdmanage modify-config'. Please refer to
drbdmanage(8) for further details.


Starting the drbdmanage server (daemon)
------------------------------------------------------------------------------

The drbdmanage server should be started automatically by D-Bus when the
drbdmanage client connects to it for the first time.

The following command can be used to check whether the drbdmanage client can
connect to the drbdmanage server, and it implicitly starts the server as
described above:
  drbdmanage ping

If the server has been started successfully or had been running already,
the response of the "ping" command is simply "pong"; otherwise, an
error message is displayed.

The server can also be started manually by issuing the following command:
  dbus-drbdmanaged-service &


drbdmanage commands overview
------------------------------------------------------------------------------

See manual page drbdmanage(8) for information on drbdmanage commands.

RELEASE/BUGFIX POLICY
------------------------------------------------------------------------------

Starting from drbdmanage 1.0.0 the project follows a three number version
scheme (x.y.z), where 'x' stands for "major", 'y' for "minor", and 'z' for a
bugfix release.

Releases that increase the major or minor number happen when development is
ready, we call them feature releases. Bugfix releases happen as soon as a bug
is discovered in a supported release, and increase the number 'z'.

- Support/Bugfixes:
We intend to support two consecutive releases. For example, as soon as we
release version 1.3.0, version 1.1.* is considered EoL and does not receive
further updates. This also applies when the major number is increased: Assume
the current version is 1.4.z, and then version 2.0.0 is released. In this case
we intend to support 2.0.* and 1.4.*. All versions prior to 1.4.* are EoL. We
support two releases overall, not two per major. If then 2.1.0 is released,
the whole 1.x.z release series is EoL.

- API/Data structure stability:
All supported versions with the same major number have a stable API. We might
add additional API calls, but we do not intentionally break/reduce the
existing API.

An increased major number means that we have introduced incompatible API
changes. We will document these changes in the release notes, but it is up to
3rd party developers to adapt their projects to the new API. Therefore, 'x' -
the major - can be considered as the API version.

- Upgrade path:
Upgrades are supported from one feature release to the next (e.g., from 1.2.*
to 1.3.*), as long as the major number stays the same.
