GitLab

Refactor module 'Ganeti.UDSServer' so the KVM daemon can reuse code
declared in this module to handle Unix domain sockets.
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Michele Tartara <mtartara@google.com>

* add user and group to 'configure.ac', 'Makefile.am' and
  'AutoConf.hs.in'
* extend 'Daemon' datatype with 'GanetiKvmd' and implement all related
  functions, such as, 'daemonName', etc.
* export KVM daemon name as constant
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Michele Tartara <mtartara@google.com>

Fix whitespace in several modules.
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Michele Tartara <mtartara@google.com>

Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Michele Tartara <mtartara@google.com>

Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Michele Tartara <mtartara@google.com>

When upgrading from any version below 2.11 to 2.11 or higher,
Ganeti will generate new RPC client certificates when upgrading
with ``gnt-cluster upgrade``. Document this behavior in the
UPGRADE notes to avoid user surprises.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Jose Lopes <jabolopes@google.com>

While, technically, Ganeti is still working without individual node
certificates, it is considered an error by gnt-cluster verify to
not have it done immediately after upgrading. So, to make automatic
upgrading work, add it as a post-upgrade hook when upgrading from
before version 2.11.0.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

This will be needed, e.g., for post-upgrade task, as they
have to decide whether a feature was not yet present at
the version started from.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

* stable-2.10
  Run postupgrade hook after upgrade
  Provide path to post-upgrade
  Add an empty post-upgrade hook
  design: support post-upgrade hooks
  Also add the current version to the intent-to-upgrade file
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Michele Tartara <mtartara@google.com>

To allow for necessary last-moment adaptions, of the new cluster,
we run the post-upgrade hook of the target version, providing
the version we originally started from.
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>

As 2.10 is the first version from which you can do automatic upgrades,
there is nothing to do when going to any other version in the 2.10
branch.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

While the general policy for Ganeti is to just accept the situation
it finds after being upgraded from an older version, in some cases
additional actions might be necessary. So support a hook for doing
so.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Our design states, that the intent-to-upgrade file contains "the current
version of ganeti, the version to change to, and the process ID". Make the
implementation fit with that design.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

The disk template section was not updated for Gluster. This commit
also refactors the section slightly by unifying the different remarks
about /etc/ganeti/file-storage-paths.

sphinx_ext is also changed in order to not hardcode too much
information in the documentation.
Signed-off-by: Santi Raffa <rsanti@google.com>
Signed-off-by: Thomas Thrainer <thomasth@google.com>
Reviewed-by: Thomas Thrainer <thomasth@google.com>

Design document for KVM daemon which is needed by the instance
shutdown detection for KVM.
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Michele Tartara <mtartara@google.com>

Distinguish declaring functions in the point-free style and using
a very similar technique to avoid parentheses (which isn't technically
point-free).
Signed-off-by: Petr Pudlak <pudlak@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

While the recommended way of downgrading from version 2.11 to 2.10
is ``gnt-cluster upgrade --to 2.10``, manual downgrade is supported.
So, the version-specific steps need to be documented in the UPGRADE
notes.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

While version 2.10 ignores any leftover client certificates, their
presence will prevent a the cluster working after an upgrade back
to version 2.11 again. So we have to remove them right at the
downgrade.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

Upgrading can have no specific knowledge about additional
tasks besides upgrading the configuration, as upgrades need
to be able to go to any future version (within the same major
version). Downgrading, however, is version specific and always
goes to the previous minor version. Therefore, the downgrade
procedure can do arbitrary specific tasks prior to switching
to the new binaries. Add a hook for this.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

Some new features, like client-specific ssl certificates, require additional
steps at downgrade, so add this to the design. Two things should be noted.

- There cannot be explicit version-specific upgrade actions; upgrades
  are carried out by the old version which cannot know about new features
  coming with the new version.

- Any version-specific downgrade tasks need to be carried out before switching
  the binaries, so that we can resume the downgrade still using the version
  knowledgeable of the new features.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

The recommended way of downgrading a cluster from 2.11 onwards
is to use the ``gnt-cluster upgrade`` command. Document this in
the section on downgrades.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

Add missing colons, and improve descriptions of parameters.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

Two command-line options are added: one for confirming that the test
has been started intentionally, and one for showing the method
invocation output, which is useful, but not always needed.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

To examine if jobs can be cancelled correctly, provide workload related
to this as well.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

One of the few leftover unused RAPI methods is the cluster modify
method. This patch tests it by setting and unsetting various safe
values.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

The instance move workload present before this patch works on 2.11, but
fails on 2.6. The 2.11 workload will still be useful should any later
version of Ganeti use it as reference, but a 2.6 workload has to be
added to make the moves checked for compatibility.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

Through the use of functions provided by the rapi QA, all the requests
related to instance moves can be exercised.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

The move-instance tool raises an exception when used with a cluster
running an earlier version of Ganeti. As the tool is meant to perform
inter-cluster moves, this situation could be encountered outside the
RAPI compatibility test.

To handle it better, this patch makes the tool fail more gracefully,
outputting a more informative error message.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

The inter-cluster instance move test is very interesting for the RAPI
compatibility tests, as it uses many RAPI requests that are otherwise
hard to exercise. It uses no command-line functionality apart from
the standard QA instance checks.

As the move-instance tool does its own checks of all the prerequisites
and desired results, not using the QA checks is acceptable for the RAPI
workload. This patch allows the checks to be skipped via an optional
argument.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

The earlier version of the Finish function assumed that checking if the
value of the response is None would suffice to check if any errors have
occurred. This is not, and this patch adjusts the function to expose
the status already known within.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

This patch introduces additional calls adding migration and failover
RAPI operations, moving a DRBD-disk template instance between nodes.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

As a helper or a warning to anyone extending the RAPI client, the
client wrapper now warns of unused methods or method arguments.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

This patch exercises the network RAPI commands.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

As query filtering was not a part of the previous workloads, this patch
adds a single example of its use.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

The query requests are done to receive data about a certain resource
type. With tests for all the resources barring networks in place, the
query workloads can be added at the point where the existence of enough
resources in the system can be confirmed, making the results of the
queries meaningful.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

This patch further extends the RAPI workload by exercising all the
group-related functionality.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

This patch further expands the workload by performing various node
operations.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

A test relying on RAPI alone cannot exercise the RecreateInstanceDisks
functionality properly - simply because it cannot damage an instance
to the point where its disks would be missing and in need of
recreation. The test is left standing simply to test if the operation
is still exposed via the interface.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>

To further expand the number of RAPI methods in the workload, the
single instance operations are added in this patch. An instance is
created, deleted, shutdown, restarted, reinstalled, renamed, and
has its disks activated and deactivated and grown.

As this increases the complexity of the code, similarly themed RAPI
operations have been extracted into separate functions.
Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>