GitLab

Move all tap-related functionality to the hv_kvm.netdev submodule. We
rename _OpenTap to OpenTap, since it will now be used as a public
function.

Also, change the hv_kvm tests to import the new code.
Signed-off-by: Apollon Oikonomopoulos <apoikos@gmail.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

Signed-off-by: Apollon Oikonomopoulos <apoikos@gmail.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

We move the HMP and QMP classes to the hv_kvm.monitor module.
Signed-off-by: Apollon Oikonomopoulos <apoikos@gmail.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

Weighing in at 3k LOC, it is probably time to split hv_kvm into a number
of modules before adding new code.
Signed-off-by: Apollon Oikonomopoulos <apoikos@gmail.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

...instead of Either String JobId.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Verify that the JSON encoding of the ClientType can correctly
be decoded.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Make ClientType a JSON instance, in the way lock owners are
already encoded in JSON on the Python side.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

While it is unlikely that lock owners will ever be represented by
something different than a job id or, exceptionally, a string, this
type will still improves type checking. Additionally, it will allow
us to make it a separate instance of JSON and thus simplify the
parts of WConfD related to communication.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Since WConfD is now the authoritative source for locks, make LuxiD
query this daemon for lock information rather than the master daemon.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

So far, the description of the locks fields was made under the assumption
that lock queries wouldn't be answered by Luxid anyway, and hence it was
enough to parse such requests. However, now luxid will answer these queries
after getting a snapshot of the locks status from wconfd. Hence make the fields
describe how to obtain the information from the data obtained at run time.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

...as locks are queried by name.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

...so that wconfd's point of view on locks can be debugged
directly.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

...so that LuxiD can ask for the lock status to answer
lock queries.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Verify that every owner mentioned in the output of listAllLocksOwners
actually owns the locks claimed.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Add a test verifying that whenever an owner owns a lock, it
is also mentioned in the output of listAllLocksOwners.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

As listAllLocks is supposed to list all locks currently in use, this should
be a superset listAllLocksOwners, i.e., of all locks actively owned by some
user.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

This function will be used to provide the information required
to answer lock queries.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

...to simplify debugging the lock status.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Make wconfd provide information about the list of all locks currently
in use.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Verify that all locks owned by someone are included in the
list of all (active) locks.
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Add a function that extracts from a LockAllocation the list
of all locks that are in use (directly or indirectly).
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Remove unused imports and update the 'buildCall' call in tests.
Signed-off-by: Petr Pudlak <pudlak@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

The client is generated automatically by Ganeti.THH.HsRPC.

It also includes helper functions for creating a client object.
Signed-off-by: Petr Pudlak <pudlak@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

It uses TH to create client functions with the corresponding signature
from a given list of server functions.
Signed-off-by: Petr Pudlak <pudlak@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

.. and also a function for extracting a type argument from a type.
Signed-off-by: Petr Pudlak <pudlak@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

.. to that they're available for other Luxi-like RPC clients as well.

While at it, rename validateResult to parseResponse to be consistent
with the names of the other functions.
Signed-off-by: Petr Pudlak <pudlak@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

... and fix an error message.
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

* Add 'ganeti-metad' to list of daemons to stop
* Update 'daemon-util' test

Note that 'ganeti-metad' is not automatically started together with
all the other daemons.  Instead, 'ganeti-metad' is only started when
it is necessary.  Nevertheless, it is stopped together with the other
daemons.
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

Note that create and import are the same LU, therefore, there are a
total of 3 calls, not 4.
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

This function is responsible for transforming the instance into a dict
and optionally overriding the OS parameters (public, private, secret).
Also, in case of failure it issues a warning.
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

This RPC is used to send instance configuration data from the master
to the node daemon, which in turn sends that data to the metadata
daemon.
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

* Use RPC transport to pass OS params to the metadata daemon, using
  the Luxi protocol
* Fix comment in 'ganeti.rpc.transport'
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

... which starts the configuration and web servers.
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

Extend metadata web server to serve the OS parameters from the shared
MVar containing the instances' configurations, indexed by their IP
address.
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

The configuration server listens on a Unix socket for connections from
the node daemon.  The node daemon sends the instance parameters to the
configuration server so they can be served through the metadata daemon
web server to the instances which have the communication mechanism
enabled.

The configuration server reads the instance parameters and, currently,
it extracts the instance's name and the instance's IP address on the
instance communication NIC.  The instance's name is used for logging
and the IP address is used to index the instance parameters, given
that instances do not authenticate with the metadata daemon, and the
only thing we know about them is their IP address.

The configuration server also extracts the OS parameters, including
public, private and secret, and creates an object containing those
parameters and their visibility.

The configuration is kept internally in an 'MVar' which will be shared
with the metadata daemon web server.
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

The metadata daemon will be responsible for receiving the instance
parameters from the node daemon and keeping them in memory.  The type
of the instance parameters in defined in a separate module because it
will be shared between the web server and the configuration server.
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

Currently, the metadata daemon is mainly a web server.  However, a new
configuration server will be introduced along with other metadata
related modules.  Therefore, this patch moves the current metadata
daemon web server to its own directory.  This module is also renamed
from 'Server' to 'WebServer'.
Signed-off-by: Jose A. Lopes <jabolopes@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>

The section describes how Luxi daemon should execute the jobs so that it
can ensure it can detect their death at every point.
Signed-off-by: Petr Pudlak <pudlak@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

.. to 2 spaces instead of 4.
Signed-off-by: Petr Pudlak <pudlak@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>