While changes with no net effect wouldn't hurt any correctness
properties, still the modification time and serial of the maintenance
entry in the configuration would be changed and the configuration
distributed to all master candidates. These unexpected configuration
changes can be confusing; they definitely do confuse some QA tests.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

Update hbal man page by adding new avoid-disk-moves=*factor* option.

Signed-off-by: Oleg Ponomarev <onponomarev@gmail.com>
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

In the test provided disk move failover and replace move normally takes
place for inst2 in order to avoid all instances running on the same node
and satisfy desired locations.

* In the first test the avoid-disk-moves *factor* is small and the i
  optmization performed by a single failover and replace move.

* In the second test the avoid-disk-moves *factor* is big enough and
  failover and replace single move is splitted into two separate steps.
  That's because gain in cluster score for the failover and replace is
  not *factor* times bigger than the gain for simple failover move.

Signed-off-by: Oleg Ponomarev <onponomarev@gmail.com>
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

avoid-disk-moves=*FACTOR* option was introduced in the "Migration speed
accounting in Hbal" design document. This option will admit disk moves
only if the gain in the cluster metrics is FACTOR times higher than the
gain achievable by non disk moves.

Signed-off-by: Oleg Ponomarev <onponomarev@gmail.com>
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

* stable-2.16
  (no changes)

* stable-2.15
  (no changes)

* stable-2.14
  Do not version generate file tools/ssl-update
  Revision bump for 2.14.1
  Update NEWS for 2.14.1

* stable-2.13
  NEWS: move 2.13.0 beta/rc to their place
  Document data collector options
  Correct NEWS file entry
  Revision bump for 2.13.2
  Update the NEWS file for 2.13.2

* stable-2.12
  Bugfix in checkInstanceMove function in Cluster.hs
  Revision bump for 2.12.5
  Update the NEWS file for 2.12.5
  Update Xen documentation in install.rst
  Clarify need for the migration_port Xen param

Conflicts:
	man/gnt-cluster.rst: take all additions

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

...to restore symmetry with OpClusterSetParams.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

* stable-2.15
  (no changes)

* stable-2.14
  Do not version generate file tools/ssl-update
  Revision bump for 2.14.1
  Update NEWS for 2.14.1

* stable-2.13
  NEWS: move 2.13.0 beta/rc to their place
  Document data collector options
  Correct NEWS file entry
  Revision bump for 2.13.2
  Update the NEWS file for 2.13.2

* stable-2.12
  Bugfix in checkInstanceMove function in Cluster.hs
  Revision bump for 2.12.5
  Update the NEWS file for 2.12.5
  Update Xen documentation in install.rst
  Clarify need for the migration_port Xen param

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

* stable-2.14
  Do not version generate file tools/ssl-update
  Revision bump for 2.14.1
  Update NEWS for 2.14.1

* stable-2.13
  NEWS: move 2.13.0 beta/rc to their place
  Document data collector options
  Correct NEWS file entry
  Revision bump for 2.13.2
  Update the NEWS file for 2.13.2

* stable-2.12
  Bugfix in checkInstanceMove function in Cluster.hs
  Revision bump for 2.12.5
  Update the NEWS file for 2.12.5
  Update Xen documentation in install.rst
  Clarify need for the migration_port Xen param

Conflicts:
	NEWS: take all additions
	configure.ac: keep all version information
	    from stable-2.15

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

It can be controlled by the same set of tags that can be
used to control harep. Moreover, describe the information
it exposes via HTTP.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

As described in the design, the maintenance daemon will only start
a new round once all jobs from the old round are finished. Add this
functionality now. As the list of jobs of the current round is also
relevant information, we expose it over HTTP. In order to do so, we
keep an in-memory copy of the job list (while the authoritative copy
is still kept in the configuration, as per our design).

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Due to the still existing configuration lock, modifications
to the configuration can temporarily be impossible. Therefore,
most configuration-modifying function return a Boolean indicating
whether the change was carried out. Add a utility function to
retry that change until it succeeds.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

In this way, the maintenance daemon can update the jobs part
of its state, while complying with the requirement that all its
state be stored in the configuration (and hence, also sufficiently
replicated).

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

...so that the maintenance daemon can always access the authoritative
version of that list.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Also, back off if a round is bad. This is usually the case,
if the communication with some essential daemon failed. In
this case, we do not want to put additional load on the system.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

...so that the maintenance daemon can query for the
interval at which to run.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

...thus providing a convenient way to control at which
interval the maintenance daemon does its repairs.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

...that will be used to set the minimal delay time for the maintenance
daemon between rounds.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

While not technically part of the cluster configuration, OpClusterSetParams
is the best place to set and modify the maintenance interval of the maintenance
daemon. Most likely, there won't be enough tunables to justify a separate
Ganeti command.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

...so that the user can modify it. As usual, we do so with
only a temporary lock acquired by WConfD.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

As per our design, the maintenance daemons stores its state
in the configuration; also, various of its aspects are
configurable. So add a corresponding configuration object.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

As per our design, the maintenance daemon operates in rounds.
To avoid putting to much load on the cluster, the daemon waits
a minimal amount of time between those rounds. This time will
be configurable, but there is a default value.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

...thus avoiding the magic constants 1000000 (number of microseconds in a
second) all over the place.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

...that takes care of creating and closing the client
properly.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

* stable-2.13
  NEWS: move 2.13.0 beta/rc to their place
  Document data collector options
  Correct NEWS file entry
  Revision bump for 2.13.2
  Update the NEWS file for 2.13.2

* stable-2.12
  Bugfix in checkInstanceMove function in Cluster.hs
  Revision bump for 2.12.5
  Update the NEWS file for 2.12.5
  Update Xen documentation in install.rst
  Clarify need for the migration_port Xen param

Conflicts:
	NEWS: take all additions
	configure.ac: keep stable-2.14 version/revision

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

...thus avoiding too frequent polling, as
suggested by the TODO entry.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

A lot of Ganeti function return a type IO (GenericResult e a)
with various failure types e. It is often necessary to combine
all those results in a generic ResultT String IO a

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Apparently during merges in the past, the NEWS entries
for 2.13.0 rc1 and 2.13.0 beta1 ended up between the entries
for 2.12.4 and 2.12.3. Move them to their rightful place now.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

* stable-2.12
  Bugfix in checkInstanceMove function in Cluster.hs
  Revision bump for 2.12.5
  Update the NEWS file for 2.12.5
  Update Xen documentation in install.rst
  Clarify need for the migration_port Xen param

Conflicts:
	NEWS: take both new entries
	configure.ac: keep version and revision of stable-2.13

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

checkInstanceMove function tries all possible moves of single instance
in order to found an optimal move. When option --no-disk-moves is
enabled, current implementation tries only Failover move while
FailoverToAny is a suitable move too. This patch fixes the bug.

Signed-off-by: Oleg Ponomarev <onponomarev@gmail.com>
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

The options --enabled-data-collectors and --data-collector-interval have
been added to gnt-cluster modify quite a while ago on stable-2.13. However
they have never been documented in the man page. Do so now.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Signed-off-by: Petr Pudlak <pudlak@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

... mentioning all the changes.

Signed-off-by: Petr Pudlak <pudlak@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

...which happend to be added by accident by
merge 6d9446fa. Remove it now.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

The Xen documentation in install.rst was out of date, describing
xm-specific changes at the point where 2.12 is mostly used with xl.
This patch removes xm-specific migration steps, references the official
Xen wiki instead of replicating information from it, removes the
VNC setup settings that are outdated for xl and probably for xm, and
slightly rewrites the documentation.

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

... depending on which toolstack is used.

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

... mentioning all the changes.

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>