Fix linter errors

Signed-off-by: John Strunk <[email protected]>

Author: JohnStrunk

controllers/mover/rclone/logfilter_test.go

@@ -65,7 +65,7 @@ getfacl: Removing leading '/' from absolute path names
 2023/01/09 20:00:52 DEBUG : S3 bucket rclone-test-0-zx42b: copied 1 directories
 2023/01/09 20:00:52 DEBUG : Waiting for deletions to finish
 2023/01/09 20:00:52 INFO  : permissions.facl: Deleted
-2023/01/09 20:00:52 INFO  : 
+2023/01/09 20:00:52 INFO  :
 Transferred:         699.051 KiB / 699.051 KiB, 100%, 0 B/s, ETA -
 Checks:                 6 / 6, 100%
 Deleted:                1 (files), 0 (dirs)
@@ -137,7 +137,7 @@ Rclone completed in 5s`
 2023/01/09 20:04:56 DEBUG : TESTDIR1/file1: Unchanged skipping
 2023/01/09 20:04:56 DEBUG : Local file system at /data: Waiting for transfers to finish
 2023/01/09 20:04:56 DEBUG : Waiting for deletions to finish
-2023/01/09 20:04:56 INFO  : 
+2023/01/09 20:04:56 INFO  :
 Transferred:         699.051 KiB / 699.051 KiB, 100%, 0 B/s, ETA -
 Checks:                 5 / 5, 100%
 Transferred:            1 / 1, 100%

controllers/mover/rsynctls/logfilter_test.go

@@ -127,7 +127,7 @@ Syncing data to 172.32.164.53:8000 ...
 2023.01.25 19:06:29 LOG6[0]: TLSv1.3 ciphersuite: TLS_AES_128_GCM_SHA256 (128-bit encryption)
 2023.01.25 19:06:29 LOG6[0]: Peer temporary key: X25519, 253 bits
 2023.01.25 19:06:29 LOG7[0]: Compression: null, expansion: null
-2023.01.25 19:06:29 LOG6[0]: Session id: 
+2023.01.25 19:06:29 LOG6[0]: Session id:
 2023.01.25 19:06:29 LOG7[0]: TLS state (connect): SSL negotiation finished successfully
 2023.01.25 19:06:29 LOG7[0]: TLS state (connect): SSL negotiation finished successfully
 2023.01.25 19:06:29 LOG7[0]: Initializing application specific data for session authenticated
@@ -564,13 +564,13 @@ Initializing inetd mode configuration
 stunnel 5.62 on x86_64-redhat-linux-gnu platform
 Compiled/running with OpenSSL 3.0.1 14 Dec 2021
 Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI
- 
+
 Global options:
 fips                   = no
 RNDbytes               = 1024
 RNDfile                = /dev/urandom
 RNDoverwrite           = yes
- 
+
 Service-level options:
 ciphers                = FIPS (with "fips = yes")
 ciphers                = PROFILE=SYSTEM (with "fips = no")

docs/design/mover-rsync.rst

@@ -59,7 +59,7 @@ Replication flow
                      | Mover  +----------=------->+ Mover  |
                      |        |                   |        |
                      \--------/                   \--------/
-    
+
 
                 Primary site                                        Secondary site
 

docs/design/rwo-affinity.rst

@@ -92,8 +92,8 @@ The application's Pod(s) can be rescheduled for a number of reasons, and VolSync
 must be able to adapt in order to avoid interfering with the application. To
 this end, it is necessary to periodically re-scan the Pods and adjust the mover
 placement appropriately. These changes follow the logic documented above,
-potentially adding, removing, or changing the `.spec.nodeName` field in the Job
-template.
+potentially adding, removing, or changing the ``.spec.nodeName`` field in the
+Job template.
 
 Limitations
 ===========

docs/usage/cli/migration.rst

@@ -56,7 +56,7 @@ PVC. Otherwise, it will use the existing PVC.
     I0302 12:50:42.498947  168200 request.go:665] Waited for 1.007067079s due to client-side throttling, not priority and fairness, request: GET:https://api.ci-ln-72rwmxb-72292.origin-ci-int-gce.dev.rhcloud.com:6443/apis/project.openshift.io/v1?timeout=32s
     I0302 12:50:43.925309  168200 migration_create.go:329] pvc: "mydata" not found, creating the same
     I0302 12:50:43.974092  168200 migration_create.go:267] Namespace: "destination" is found, proceeding with the same
-    I0302 12:50:44.021410  168200 migration_create.go:314] Created Destination PVC: "mydata" in NameSpace: "destination" and Cluster: "" 
+    I0302 12:50:44.021410  168200 migration_create.go:314] Created Destination PVC: "mydata" in NameSpace: "destination" and Cluster: ""
     I0302 12:50:44.073745  168200 migration_create.go:357] Created ReplicationDestination: "destination-mydata-migration-dest" in Namespace: "destination" and Cluster: ""
 
     $ kubectl get -n destination pvc/mydata
@@ -181,4 +181,3 @@ We can now start a pod attached to the PVC and view the data:
 
     $ kubectl -n destination exec -it pod/busybox -- du -sh /mnt
     655.4M	/mnt
-

docs/usage/index.rst

@@ -59,4 +59,4 @@ Volume Populator
 ================
 
 VolSync provides a :doc:`Volume Populator <volume-populator/index>` to allow creation of PVCs that reference a
-ReplicationDestination as a dataSourceRef.
+ReplicationDestination as a dataSourceRef.

docs/usage/rclone/database_example.rst

@@ -36,7 +36,7 @@ Add a new database.
 
 .. code:: console
 
-   $ kubectl exec --stdin --tty -n source `kubectl get pods -n source | grep mysql | awk '{print $1}'` -- /bin/bash
+   $ kubectl exec --stdin --tty -n source $(kubectl get pods -n source | grep mysql | awk '{print $1}') -- /bin/bash
    $ mysql -u root -p$MYSQL_ROOT_PASSWORD
    > show databases;
    +--------------------+
@@ -105,7 +105,7 @@ lines:
     Type:                  Reconciled
   Next Sync Time:          2021-01-18T22:00:00Z
 
-At ``Next Sync Time`` VolSync will create the next Rclone data mover job. 
+At ``Next Sync Time`` VolSync will create the next Rclone data mover job.
 
 -----------------------------------------
 
@@ -150,7 +150,7 @@ exists.
 
 .. code:: console
 
-   $ kubectl exec --stdin --tty -n dest `kubectl get pods -n dest | grep mysql | awk '{print $1}'` -- /bin/bash
+   $ kubectl exec --stdin --tty -n dest $(kubectl get pods -n dest | grep mysql | awk '{print $1}') -- /bin/bash
    $ mysql -u root -p$MYSQL_ROOT_PASSWORD
    > show databases;
    +--------------------+

docs/usage/rclone/index.rst

@@ -74,7 +74,7 @@ An example source configuration is shown below:
       # The VSC to use if the copy method is Snapshot (default if omitted)
       volumeSnapshotClassName: my-vsc-name
 
-Since the ``copyMethod`` specified above is ``Snapshot``, the Rclone data mover creates a ``VolumeSnapshot`` 
+Since the ``copyMethod`` specified above is ``Snapshot``, the Rclone data mover creates a ``VolumeSnapshot``
 of the source pvc ``mysql-pv-claim``. Then it converts this snapshot back into a PVC.
 If ``copyMethod: Clone`` were used, the temporary, point-in-time copy would be
 created by cloning the source PVC to a new PVC directly. This is more efficient,
@@ -345,4 +345,4 @@ of ``secretName``, for example:
        # ... other fields omitted ...
        customCA:
          configMapName: tls-configmap-name
-         key: ca.crt
+         key: ca.crt

docs/usage/restic/database_example.rst

@@ -50,7 +50,7 @@ Add a new database:
 
 .. code-block:: console
 
-   $ kubectl exec --stdin --tty -n source `kubectl get pods -n source | grep mysql | awk '{print $1}'` -- /bin/bash
+   $ kubectl exec --stdin --tty -n source $(kubectl get pods -n source | grep mysql | awk '{print $1}') -- /bin/bash
 
    $ mysql -u root -p$MYSQL_ROOT_PASSWORD
 
@@ -277,7 +277,7 @@ exists.
 
 .. code-block:: console
 
-   $ kubectl exec --stdin --tty -n dest `kubectl get pods -n dest | grep mysql | awk '{print $1}'` -- /bin/bash
+   $ kubectl exec --stdin --tty -n dest $(kubectl get pods -n dest | grep mysql | awk '{print $1}') -- /bin/bash
    $ mysql -u root -p$MYSQL_ROOT_PASSWORD
    > show databases;
    +--------------------+

docs/usage/restic/index.rst

@@ -352,4 +352,4 @@ of ``secretName``, for example:
        # ... other fields omitted ...
        customCA:
          configMapName: tls-configmap-name
-         key: ca.crt
+         key: ca.crt

docs/usage/rsync/database_example.rst

@@ -127,7 +127,7 @@ mysql pod running in the source namespace.
 
 .. code:: console
 
-   $ kubectl exec --stdin --tty -n source `kubectl get pods -n source | grep mysql | awk '{print $1}'` -- /bin/bash
+   $ kubectl exec --stdin --tty -n source $(kubectl get pods -n source | grep mysql | awk '{print $1}') -- /bin/bash
    $ mysql -u root -p$MYSQL_ROOT_PASSWORD
    > show databases;
    +--------------------+
@@ -182,7 +182,7 @@ exists.
 
 .. code:: console
 
-   $ kubectl exec --stdin --tty -n dest `kubectl get pods -n dest | grep mysql | awk '{print $1}'` -- /bin/bash
+   $ kubectl exec --stdin --tty -n dest $(kubectl get pods -n dest | grep mysql | awk '{print $1}') -- /bin/bash
    $ mysql -u root -p$MYSQL_ROOT_PASSWORD
    > show databases;
    +--------------------+

docs/usage/rsync/external_rsync.rst

@@ -18,4 +18,3 @@ synchronization of data into a Kubernetes PVC, please see:
 
 - :doc:`CLI/kubectl plugin installation<../cli/index>`
 - :doc:`VolSync migration command<../cli/migration>`
-

docs/usage/rsync/ssh_keys.rst

@@ -35,7 +35,7 @@ Two key pairs need to be generated. The first SSH key will called ``destination`
    | .o. o...        |
    +----[SHA256]-----+
 
-The second SSH key will be called `source`:
+The second SSH key will be called ``source``:
 
 .. code::
 
@@ -44,7 +44,7 @@ The second SSH key will be called `source`:
    Your identification has been saved in source
    Your public key has been saved in source.pub
    The key fingerprint is:
-   SHA256:NEQNMNsgR43Y3c2dWMyit70JagmbCLNRfakWhWORENU 
+   SHA256:NEQNMNsgR43Y3c2dWMyit70JagmbCLNRfakWhWORENU
    The key's randomart image is:
    +---[RSA 4096]----+
    |    .+OX*O o *.. |

docs/usage/syncthing/index.rst

@@ -29,11 +29,11 @@ Syncthing also includes an introducer feature which allows one device to be conn
 This can be used to create a hub-and-spoke model for replication, or any other kind of network.
 
 When a ReplicationSource is created and configured to sync a PVC with other peers, all of the connected peers will maintain their
-own Volume containing the synced data. To detect file changes, Syncthing employs two methods: a filesystem watcher, which notifies 
+own Volume containing the synced data. To detect file changes, Syncthing employs two methods: a filesystem watcher, which notifies
 Syncthing of any changes to the local filesystem, and a full filesystem scan which occurs routinely at a specified interval (default is an hour).
 Since Syncthing is an "always-on" synchronization system, ReplicationSources will report their synchronization status as always being 'in-progress'.
 
-VolSync uses a custom-built Syncthing mover which disables the use of relay servers and global announce, and relying instead on 
+VolSync uses a custom-built Syncthing mover which disables the use of relay servers and global announce, and relying instead on
 being provided with the addresses of other Syncthing peers directly.
 
 
@@ -69,7 +69,7 @@ Here's an example of a Syncthing-based ReplicationSource.
           introducer: false
 
 The above ReplicationSource tells VolSync that it should use the Syncthing replication method in order
-to sync the ``todo-database`` volume. 
+to sync the ``todo-database`` volume.
 
 A service type of ``ClusterIP`` is used to expose the Syncthing data port, allowing us to connect with other peers within the cluster.
 In order for Syncthing to connect to peers outside of the cluster, you will need to either use
@@ -117,7 +117,7 @@ configVolumeAccessModes
 Source Status
 -------------
 
-Once the ReplicationSource has been deployed and Syncthing has properly configured itself, 
+Once the ReplicationSource has been deployed and Syncthing has properly configured itself,
 it will populate the ``.status.syncthing`` field with information about your Syncthing node.
 
 Here's an example of a ReplicationSource with a status:
@@ -229,7 +229,7 @@ For Example, suppose we have the following two ReplicationSources:
   metadata:
     name: alice-rs
   spec:
-    sourcePVC: alice-data 
+    sourcePVC: alice-data
     syncthing:
       serviceType: ClusterIP
       peers:
@@ -255,7 +255,7 @@ For Example, suppose we have the following two ReplicationSources:
 
 
 Here, ``alice-rs`` is being configured by ``bob-rs`` to act as an introducer for any nodes that are currently connected to the shared PVC.
-At the moment, there are only ``N=2`` Syncthing nodes in the entire cluster. 
+At the moment, there are only ``N=2`` Syncthing nodes in the entire cluster.
 
 
 Adding More Spokes
@@ -264,7 +264,7 @@ Adding More Spokes
 Now, let's suppose that we want to connect Charlie to everyone in the current cluster,
 but without having to append his address and ID to the two other existing nodes.
 
-In order to do this, we will need to update Alice's ``peers`` to include Charlie's Syncthing ID and address, 
+In order to do this, we will need to update Alice's ``peers`` to include Charlie's Syncthing ID and address,
 as well as update Charlie's ``peers`` to include Alice with ``introducer: true`` set.
 
 .. code-block:: yaml
@@ -275,7 +275,7 @@ as well as update Charlie's ``peers`` to include Alice with ``introducer: true``
   metadata:
     name: alice-rs
   spec:
-    sourcePVC: alice-data 
+    sourcePVC: alice-data
     syncthing:
       serviceType: ClusterIP
       peers:
@@ -317,7 +317,7 @@ Removing Spokes
 
 In order to remove a spoke from the cluster, simply remove it from the Hub's ``peers`` list.
 
-For example, if Alice wants to remove Charlie, all she needs to do is remove the entry corresponding to his ID, and 
+For example, if Alice wants to remove Charlie, all she needs to do is remove the entry corresponding to his ID, and
 the rest of the Syncthing cluster will automatically remove him from their connections.
 
 
@@ -330,7 +330,7 @@ the rest of the Syncthing cluster will automatically remove him from their conne
   metadata:
     name: alice-rs
   spec:
-    sourcePVC: alice-data 
+    sourcePVC: alice-data
     syncthing:
       serviceType: ClusterIP
       peers:
@@ -369,7 +369,7 @@ Cyclic introducers
 ------------------
 
 Syncthing introducers also contain a mechanism to automatically re-add introduced nodes if they were disconnected
-for whatever reason. This means that if you configure two nodes as each other's introducer, you will never 
+for whatever reason. This means that if you configure two nodes as each other's introducer, you will never
 be able to disconnect them as they'll continue to re-add each other until the end of time.
 
 
@@ -380,9 +380,9 @@ Communicating With Syncthing
 Unlike the other data movers, Syncthing never stops running. This changes our approach of controlling it to
 having Syncthing always be running, and communicating with it through it's REST API.
 
-Syncthing has a REST API which handles connections through HTTPS. In order to do this securely, 
+Syncthing has a REST API which handles connections through HTTPS. In order to do this securely,
 VolSync provisions a self-signed certificate and key for the Syncthing REST API, passing the generated
-certificate and key to Syncthing on first launch, and adding the Public Key PEM to VolSync's root CA bundle. 
+certificate and key to Syncthing on first launch, and adding the Public Key PEM to VolSync's root CA bundle.
 
 You can provide a custom HTTPS key/certificate pair by overriding the Secret which VolSync uses to store its
 communication credentials for Syncthing.
@@ -416,5 +416,4 @@ would require you to name the ReplicationSource "my-replication-source".
 
 .. note::
   This Secret must be created **before** creating the ReplicationSource.
-  Otherwise, Syncthing will generate its own set of credentials and ignore yours.  
-
+  Otherwise, Syncthing will generate its own set of credentials and ignore yours.

docs/usage/syncthing/syncthing_example.rst

@@ -5,7 +5,7 @@ Syncthing Dokuwiki Example
 
 .. note::
   This tutorial requires the usage of LoadBalancer to expose applications
-  from within the cluster. If you are running a KIND cluster, please 
+  from within the cluster. If you are running a KIND cluster, please
   follow this guide to install metallb if you haven't already: https://kind.sigs.k8s.io/docs/user/loadbalancer/
 
 
@@ -24,7 +24,7 @@ Ensure that we can access the dokuwiki application by obtaining the external IP
 
 
 .. code-block:: console
-  
+
   $ kubectl get service -n dokuwiki-east dokuwiki-service
   NAME               TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)          AGE
   dokuwiki-service   LoadBalancer   10.96.231.229   172.18.255.200   5196:30113/TCP   16m
@@ -41,11 +41,11 @@ Once opened, you should see a page like this:
 
 
 Now let's populate our DokuWiki with its first page, and what better subject to
-talk about then the Syncthing data mover? 
+talk about then the Syncthing data mover?
 
 Create a new page on the DokuWiki website with the following contents:
 
-.. code-block:: 
+.. code-block::
 
   Syncthing is a data mover that allows you to synchronize your data across multiple devices.
   It's an awesome tool that you should try out if you haven't already.
@@ -61,9 +61,9 @@ Now let's create a Syncthing-based ReplicationSource to synchronize the data wit
 Let's retrieve our ReplicationSource's Syncthing information once it becomes available:
 
 .. code-block:: console
-  
+
   $ kubectl get replicationsource -n dokuwiki-east sync-dokuwiki \
-    -o jsonpath='{.status.syncthing}' -w 
+    -o jsonpath='{.status.syncthing}' -w
   {"ID":"TMBYRB4-EIINYAW-ZFBX4LV-7FE37NT-BLQPSKB-P2BFIPW-QW6ST3C-PSU7UQD","address":"tcp://10.96.217.239:22000"}
 
 
@@ -114,7 +114,7 @@ You should see empty pages for both ``dokuwiki-west`` and ``dokuwiki-central``.
 Let's change this by creating Syncthing-based ReplicationSources in each of these namespaces,
 and configuring them to use ``dokuwiki-east`` as their introducer node.
 
-Using the information that we obtained from the ReplicationSource in ``dokuwiki-east`` earlier, 
+Using the information that we obtained from the ReplicationSource in ``dokuwiki-east`` earlier,
 create a ReplicationSource with the following contents and apply it in each namespace:
 
 .. code-block:: bash
@@ -231,7 +231,7 @@ We can also see that ``dokuwiki-central`` was introduced and connected to ``doku
   ]
 
 
-Now, let's get the external IPs to the ``dokuwiki-west`` and ``dokuwiki-central`` applications and 
+Now, let's get the external IPs to the ``dokuwiki-west`` and ``dokuwiki-central`` applications and
 view them in our browser:
 
 .. code-block:: shell
@@ -258,7 +258,7 @@ And here's how it looks in the ``dokuwiki-west`` namespace:
   :width: 100%
   :alt: DokuWiki in ``dokuwiki-west`` namespace synced with Syncthing
 
-Now let's create a new page from the ``dokuwiki-west`` namespace, 
+Now let's create a new page from the ``dokuwiki-west`` namespace,
 click on the URL bar at the and append ``/dokuwiki-west`` to the end of the URL, like this:
 
 .. image:: images/dokuwiki-west-urlbar.png
@@ -267,7 +267,7 @@ click on the URL bar at the and append ``/dokuwiki-west`` to the end of the URL,
   :alt: URL bar appending ``/dokuwiki-west`` to the current DokuWiki URL
 
 This should present us with a new page containing the message: "this topic does not exist yet."
-Well let's change that: click on the "Create this page" button and fill it with 
+Well let's change that: click on the "Create this page" button and fill it with
 the content of your choosing.
 In our case, we're going to make a page for our ``dokuwiki-west`` namespace.
 
@@ -299,4 +299,4 @@ appear in the ``dokuwiki-central`` tab:
 
 
 And voila! You have just created a fully-connected Syncthing cluster in Kubernetes using VolSync,
-and made use of it to synchronize data across a distributed application.
+and made use of it to synchronize data across a distributed application.