HAREP(1) Ganeti | Version 3.0.0

NAME

harep - Ganeti auto-repair tool

SYNOPSIS

harep [ [-L | --luxi ] = socket ] [ --job-delay = seconds ] [ --dry-run ]

harep --version

DESCRIPTION

Harep is the Ganeti auto-repair tool. It is able to detect that an instance is broken and to generate a sequence of jobs that will fix it, in accordance to the policies set by the administrator. At the moment, only repairs for instances using the disk templates plain or drbd are supported.

Harep is able to recognize what state an instance is in (healthy, suspended, needs repair, repair disallowed, pending repair, repair failed) and to lead it through a sequence of steps that will bring the instance back to the healthy state. Therefore, harep is mainly meant to be run regularly and frequently using a cron job, so that it can actually follow the instance along all the process. At every run, harep will update the tags it adds to instances that describe its repair status, and will submit jobs that actually perform the required repair operations.

By default, harep only reports on the health status of instances, but doesn't perform any action, as they might be potentially dangerous. Therefore, harep will only touch instances that it has been explicitly authorized to work on.

The tags enabling harep, can be associated to single instances, or to a nodegroup or to the whole cluster, therefore affecting all the instances they contain. The possible tags share the common structure:

ganeti:watcher:autorepair:<type>

where <type> can have the following values:

Each element in the list of tags, includes all the authorizations of the previous one, with fix-storage being the least powerful and reinstall being the most powerful.

In case multiple autorepair tags act on the same instance, only one can actually be active. The conflict is solved according to the following rules:

  1. if multiple tags are in the same object, the least destructive takes precedence.
  2. if the tags are across objects, the nearest tag wins.

Example: A cluster has instances I1 and I2, where I1 has the failover tag, and the cluster has both fix-storage and reinstall. The I1 instance will be allowed to failover, the I2 instance only to fix-storage.

LIMITATIONS

Harep doesn't do any hardware failure detection on its own, it relies on nodes being marked as offline by the administrator.

Also harep currently works only for instances with the drbd and plain disk templates.

Using the data model of htools(1), harep cannot distinguish between drained and offline nodes. In particular, it will (permission provided) failover instances also in situations where a migration would have been enough. In particular, handling of node draining is better done using hbal(1), which will always submit migration jobs, however is the permission to fall back to failover.

These issues will be addressed by a new maintenance daemon in future Ganeti versions, which will supersede harep.

OPTIONS

The options that can be passed to the program are as follows:

-L socket, --luxi=*socket*

collect data via Luxi, optionally using the given socket path.

--job-delay=*seconds*

insert this much delay before the execution of repair jobs to allow the tool to continue processing instances.

--dry-run

only show which operations would be carried out, but do nothing, even on instances where tags grant the appropriate permissions. Note that harep keeps the state of repair operations in instance tags; therefore, only the operations of the next round of actions can be inspected.

REPORTING BUGS

Report bugs to the project's issue tracker or contact the developers using the Ganeti mailing list.

SEE ALSO

Ganeti overview and specifications: ganeti(7) (general overview), ganeti-os-interface(7) (guest OS definitions), ganeti-extstorage-interface(7) (external storage providers).

Ganeti commands: gnt-cluster(8) (cluster-wide commands), gnt-job(8) (job-related commands), gnt-node(8) (node-related commands), gnt-instance(8) (instance commands), gnt-os(8) (guest OS commands), gnt-storage(8) (storage commands), gnt-group(8) (node group commands), gnt-backup(8) (instance import/export commands), gnt-debug(8) (debug commands).

Ganeti daemons: ganeti-watcher(8) (automatic instance restarter), ganeti-cleaner(8) (job queue cleaner), ganeti-noded(8) (node daemon), ganeti-rapi(8) (remote API daemon).

Ganeti htools: htools(1) (generic binary), hbal(1) (cluster balancer), hspace(1) (capacity calculation), hail(1) (IAllocator plugin), hscan(1) (data gatherer from remote clusters), hinfo(1) (cluster information printer), mon-collector(7) (data collectors interface).

COPYRIGHT

Copyright (C) 2006-2015 Google Inc. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.