- Jun 14, 2010
-
-
Michael Hanselmann authored
This “magic” value will be used to ensure that we don't accidentially connect to the wrong daemon (e.g. due to a bug), comparable to DRBD's per-disk secret. Just depending on the SSL certificate isn't enough as it's always per instance and not per disk. Signed-off-by:
Michael Hanselmann <hansmi@google.com> Reviewed-by:
Guido Trotter <ultrotter@google.com>
-
Michael Hanselmann authored
The hostname and port received from the remote cluster should be validated, just in case. Signed-off-by:
Michael Hanselmann <hansmi@google.com> Reviewed-by:
Guido Trotter <ultrotter@google.com>
-
- Jun 11, 2010
-
-
Michael Hanselmann authored
- Increase timeouts from 10 to 30 seconds (this still breaks when the machine is busy, e.g. using bonnie++) - Depend on only one timeout per test instead of three - Reset variables before each test Signed-off-by:
Michael Hanselmann <hansmi@google.com> Reviewed-by:
Iustin Pop <iustin@google.com>
-
Michael Hanselmann authored
Signed-off-by:
Michael Hanselmann <hansmi@google.com> Reviewed-by:
Iustin Pop <iustin@google.com>
-
Michael Hanselmann authored
Generating certificates can be slow. Signed-off-by:
Michael Hanselmann <hansmi@google.com> Reviewed-by:
Iustin Pop <iustin@google.com>
-
- Jun 03, 2010
-
-
Michael Hanselmann authored
Apart from improved logging, one race condition is fixed. If the destination's status file became available, the port would be returned immediately, even if it was still “None”. Most of the time it worked, but not always. Now an additional check ensures the port evaluates to True. Signed-off-by:
Michael Hanselmann <hansmi@google.com> Reviewed-by:
Guido Trotter <ultrotter@google.com>
-
Michael Hanselmann authored
Signed-off-by:
Michael Hanselmann <hansmi@google.com> Reviewed-by:
Guido Trotter <ultrotter@google.com>
-
- May 21, 2010
-
-
Michael Hanselmann authored
For example, exports on the same node shouldn't be compressed. Signed-off-by:
Michael Hanselmann <hansmi@google.com> Reviewed-by:
Guido Trotter <ultrotter@google.com>
-
- Apr 27, 2010
-
-
Michael Hanselmann authored
- Progress messages - Log output on errors - Listen timeout tests Signed-off-by:
Michael Hanselmann <hansmi@google.com> Reviewed-by:
René Nussbaumer <rn@google.com>
-
Michael Hanselmann authored
Until now, exactly one attempt was made to establish a connection. If it failed, the whole import/export for the disk in question aborted. Retrying will make it more reliable. Unfortunately the listening part can't be made completely resiliant against DoS attacks without larger and complex changes to the daemon and using socat's EXEC: address combined with forking. Signed-off-by:
Michael Hanselmann <hansmi@google.com> Reviewed-by:
René Nussbaumer <rn@google.com>
-
- Apr 16, 2010
-
-
Michael Hanselmann authored
This backend daemon for instance import and export will be used to transfer instance data to other machines. It is implemented in a generic way to support different ways of data input and output. The third-party program “socat”, which is already used by the KVM hypervisor abstraction, is used to connect to remote machines using SSL/TLS. After starting the child processes in a separate process group, the import/export daemon monitors their output and updates a status file regularily. This status file can then be read by ganeti-noded (not in this patch). Three I/O methods are supported: Raw disk, file and script. Each of these can be used for import and export. Similar to daemon-util, an incomplete set of tests written in Bash is included. Two future enhancements are planned: - Run parts of the command chain as a dedicated user (privilege separation). - Currently users of this daemon have to poll the status file while data is transferred. This is inefficient and creates unnecessary delays. By adding “dd” into the chain and sending it SIGUSR1 regularily, we can get some statistics, optimize the polling frequenc and even provide the user with an ETA (which isn't available with all current methods to import/export instance data). Signed-off-by:
Michael Hanselmann <hansmi@google.com> Reviewed-by:
Iustin Pop <iustin@google.com>
-