Merge ~pieq/checkbox-ng:checkbox-remote-nomenclature into checkbox-ng:master

[Pierre Equoy]

Replaced master/slave with remote/service nomenclature. Sometimes, "device" is used instead of "service" when it makes more sense.

Tests run:

For the docs: built the documentation locally using `./setup.py build_sphinx -b html` and verified that the changes were taken into account.

For checkbox-ng: launched the modified `checkbox-cli remote`, pressed Ctrl+C and verified that there was no more mention of mater/slave.

Note: in the device-daemon.rst file, there are still a few commands that mention slave, but they are related to Checkbox-snappy which is deprecated and is planned to be removed at any point, so I decided to leave the commands like this for now and once the removal of checkbox-snappy happens[1], these commands will be adjusted.

[1] https://warthogs.atlassian.net/browse/CHECKBOX-88

[Jonathan Cave (jocave)]

Some suggestions included inline.

There may be some more uses of "Device" that I missed where I would consider using DUT or service as appropriate.

These really are opinion though and understand others probably have differing opinions

review: Needs Fixing

[Jonathan Cave (jocave)]

Having looked at some other docs recently, I find it frustrating that we mix use of SUT in some of our docs and DUT in others. I don't think this helps with general confusion about overloaded terms.

I would be really helpful if we could have a common glossary for Cert.

[Jeff Lane  (bladernr)]

I have used SUT out of habit since I started here, I had never heard
DUT until more closely interacting with the IoT team. I definitely
agree on needing common nomenclature for things so that everyone knows
exactly what is being described.

On Tue, Aug 16, 2022 at 9:06 AM Jonathan Cave
<email address hidden> wrote:
>
> Having looked at some other docs recently, I find it frustrating that we mix use of SUT in some of our docs and DUT in others. I don't think this helps with general confusion about overloaded terms.
>
> I would be really helpful if we could have a common glossary for Cert.
> --
> https://code.launchpad.net/~pieq/checkbox-ng/+git/checkbox-ng/+merge/427277
> Your team Checkbox Administrators is subscribed to branch checkbox-ng:master.
>
> Launchpad-Message-Rationale: Subscriber @checkbox-admins
> Launchpad-Message-For: checkbox-admins
> Launchpad-Notification-Type: code-review
> Launchpad-Branch: ~checkbox-dev/checkbox-ng/+git/checkbox-ng:master
> Launchpad-Project: checkbox-ng
>

--
Jeff Lane
Engineering Manager
IHV/OEM Alliances and Server Certification

"Entropy isn't what it used to be."

Unmerged commits

df178e9... by Pierre Equoy on 2022-07-22

Change:urwid: Use Remote and Device instead of Master and Slave

eceaec1... by Pierre Equoy on 2022-07-22

Change:docs: use Remote and Device terms instead of Master and Slave

diff --git a/checkbox_ng/urwid_ui.py b/checkbox_ng/urwid_ui.py
index 9d4af34..fd8ec41 100644
--- a/checkbox_ng/urwid_ui.py
+++ b/checkbox_ng/urwid_ui.py
@@ -691,11 +691,11 @@ def interrupt_dialog(host):
         ('start', 'dark green,bold', 'black'),
     ]
     choices = [
-        _("Cancel the interruption and resume the session (ESC)"),
+        _("Cancel the interruption and resume the session (Esc)"),
         _("Kill test in progress and move on to next"),
-        _("Disconnect the master (Same as CTRL+C)"),
-        _("Stop the checkbox slave @{}".format(host)),
-        _("Abandon the session on the slave @{}".format(host)),
+        _("Disconnect the remote (Same as Ctrl+C)"),
+        _("Stop the Checkbox service @{}".format(host)),
+        _("Abandon the session on the device @{}".format(host)),
     ]
     footer_text = [
         ('Press '), ('start', '<Enter>'), (' or '),
diff --git a/docs/_images/interrupt.png b/docs/_images/interrupt.png
index e17390b..d8dc521 100644
Binary files a/docs/_images/interrupt.png and b/docs/_images/interrupt.png differ
diff --git a/docs/configs.rst b/docs/configs.rst
index 0bf3b41..43ef652 100644
--- a/docs/configs.rst
+++ b/docs/configs.rst
@@ -28,16 +28,16 @@ value resolution is as follows:
 Configs with Checkbox Remote
 ============================
 
-When the Checkbox Slave starts, it looks for config files in the same places
-that local Checkbox session would look (on the Slave side).
-If the Master uses a Launcher, then the values from that Launcher take
-precedence over the values from configs on the Slave side.
+When the Checkbox Device starts, it looks for config files in the same places
+that local Checkbox session would look (on the Device side).
+If the Remote uses a Launcher, then the values from that Launcher take
+precedence over the values from configs on the Device side.
 
 Example:
 
 ::
 
-    # checkbox.conf on the Slave
+    # checkbox.conf on the Device
 
     [environment]
     FOO = 12
@@ -45,7 +45,7 @@ Example:
 
 ::
 
-    # Launcher used by the master
+    # Launcher used by the Remote
 
     # (...)
     [environment]
@@ -53,5 +53,5 @@ Example:
 
 A Checkbox job that runs ``echo $FOO $BAR`` would print ``42 6``
 
-Note that ``BAR`` is still available even though Master used Launcher that did
+Note that ``BAR`` is still available even though Remote used Launcher that did
 not define it.
diff --git a/docs/index.rst b/docs/index.rst
index 4d39664..7cb67c9 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -61,7 +61,7 @@ Table of contents
    understanding.rst
    tutorials.rst
    remote.rst
-   slave-daemon.rst
+   service-daemon.rst
    units/index.rst
    bugs.rst
    stack.rst
diff --git a/docs/launcher-tutorial.rst b/docs/launcher-tutorial.rst
index ec5339a..2692e78 100644
--- a/docs/launcher-tutorial.rst
+++ b/docs/launcher-tutorial.rst
@@ -381,14 +381,14 @@ Daemon-specific configuration
 ``[daemon]``
 
 Beginning of the daemon-specific section.
-Settings in this section only apply to sessions that are run by checkbox-slave
-spawned as a daemon.
+Settings in this section only apply to sessions that are run by checkbox
+service spawned as a daemon.
 
 ``normal_user``
 
 Username to use when job doesn't specify which user to run as.
 
-Checkbox-slave daemon is run by root so in order to run some jobs as an
+Checkbox service daemon is run by root so in order to run some jobs as an
 unprivileged user this variable can be used.
 
 
diff --git a/docs/remote.rst b/docs/remote.rst
index 4d97c0b..5cbc7c9 100644
--- a/docs/remote.rst
+++ b/docs/remote.rst
@@ -23,73 +23,69 @@ Remote sends lean data only.
 Nomenclature
 ============
 
-*Checkbox Slave* - the Checkbox instance that runs on the System or Device
-under test and _executes_ the tests.
+**Checkbox Device**: the Checkbox instance that runs on the System or Device
+Under Test (SUT/DUT) and **executes** the tests.
 
-*Checkbox Master* - Checkbox instance that controls the execution of tests on
-the Slave, such as a laptop.
+**Checkbox Remote**: Checkbox instance that controls the execution of tests on
+the Device, such as a laptop.
 
 Invocation:
-  Slave:
-    ``checkbox-cli slave``
+  Device:
+    ``checkbox-cli service``
 
-  Master:
-    ``checkbox-cli master HOST [/PATH/TO/LAUNCHER]``
+  Remote:
+    ``checkbox-cli remote HOST [/PATH/TO/LAUNCHER]``
 
-    HOST can be an IP or a hostname that your device can resolve.
+    ``HOST`` can be an IP or a hostname that your device can resolve.
 
-    LAUNCHER (optional) a launcher file to use that exists somewhere on the
-    machine you are using as the Master.
+    ``LAUNCHER`` (optional) a launcher file to use that exists somewhere on the
+    machine you are using as the Remote.
 
 
   Example:
-    ``checkbox-cli master dut8.local /home/ubuntu/testplans/sutton-client``
+    ``checkbox-cli remote dut8.local /home/ubuntu/testplans/sutton-client``
 
 Custom port
 ===========
 
-By default Slave listens on port 18871. To change that ``--port`` option can be
-used. The same option used on Master specifies which port to connect to.
+By default Device listens on port 18871. To change that ``--port`` option can be
+used. The same option used on Remote specifies which port to connect to.
 
   Example:
-    ``checkbox-cli slave --port 10101``
+    ``checkbox-cli service --port 10101``
 
-    ``checkbox-cli master dut8.local --port 10101``
+    ``checkbox-cli remote dut8.local --port 10101``
 
 Session control
 ===============
 
-  While Master is connected, sending SIGINT (hitting ctrl+c) to the application
-  invokes the interrupt screen:
+While Remote is connected, sending SIGINT (hitting ``Ctrl+C``) to the application
+invokes the interrupt screen:
 
   .. image:: _images/interrupt.png
 
-  First action is "Cancel the interruption", which returns to the session (Does
-  nothing). You can also press ESC on the Interruption screen to select that
-  action.
-
-  Second action is "Disconnect the master". It leaves the session on the Slave
-  running, but the Master exits. You can also hit ctrl+c again to select that
-  action (terminate the master). You can reconnect to the Slave and resume
-  testing like the interruption never happened.
-
-  Third action is "Stop the Checkbox slave". It stops the session and terminates
-  the Checkbox process on the Slave. It also stops the master.
-
-  Fourth action is "Abandon the session". It stops and _removes_ the session on
-  the Slave and immediately starts another one. After the new session is started
-  Master is greeted with test plan selection screen. This is a good moment to
-  disconnect the master if you wish to run testing at a later time.
+- "Cancel the interruption": returns to the session (does nothing). You can
+  also press the ``Esc`` key on the Interruption screen to select that action.
+- "Disconnect the remote": leaves the session on the Device running, but the
+  Remote exits. You can also hit ``Ctrl+C`` again to select that action
+  (terminate the Remote). You can reconnect to the Device and resume testing as
+  if the interruption never happened.
+- "Stop the Checkbox service". It stops the session and terminates the Checkbox
+  process on the Device. It also stops the Remote.
+- "Abandon the session": stops and **removes** the session on the Device and
+  immediately starts another one. After the new session is started, Remote is
+  greeted with the test plan selection screen. This is a good moment to
+  disconnect the Remote if you wish to run testing at a later time.
 
 Remote session characteristics
 ==============================
 
-Differences between remote session and a local one are:
+Differences between a remote session and a local one are:
 
-  * Unless session is explicitly abandoned, Checkbox Slave always resumes the
-    last session.
-  * After testing is done, Slave starts another session
-  * Submission is done from the Master by default 
-    (use: ``local_submission = No`` in launcher or config to change that)
-  * When Master reconnects mid interactive test, the test is restarted.
-  * Hitting ctrl+c in Master doesn't interrupt the running test.
+- Unless session is explicitly abandoned, Checkbox Device always resumes the
+  last session.
+- After testing is done, Device starts another session.
+- Submission is done from the Remote by default (use: ``local_submission = No``
+  in launcher or config to change that).
+- When Remote reconnects mid-interactive test, the test is restarted.
+- Hitting ``Ctrl+C`` in Remote doesn't interrupt the running test.
diff --git a/docs/slave-daemon.rst b/docs/service-daemon.rst
similarity index 74%
rename from docs/slave-daemon.rst
rename to docs/service-daemon.rst
index 33ddd34..6ecb64e 100644
--- a/docs/slave-daemon.rst
+++ b/docs/service-daemon.rst
@@ -1,10 +1,10 @@
-.. _daemonic_slave:
+.. _daemonic_service:
 
-Checkbox Slave Daemon Service
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Checkbox Daemon Service
+^^^^^^^^^^^^^^^^^^^^^^^
 
 Checkbox snaps supporting Checkbox Remote functionality usually come with a
-Systemd service that can ensure Checkbox Slave is loaded and active.
+Systemd service that can ensure Checkbox is loaded and active.
 
 .. note::
 
@@ -44,32 +44,32 @@ To disable the daemon run
 Stopping the daemon
 ===================
 
-If you wish to stop currently running Slave instance, run
+If you wish to stop currently running Device instance, run
 
 .. code-block:: bash
 
     $ sudo systemctl stop snap.checkbox-snappy.remote-slave.service
 
-Or press ctrl+c on the Master controlling that particular slave, and select
-``stop the checkbox slave @your_host``.
+Or press ``Ctrl+C`` on the Remote controlling that particular Device, and select
+``stop the Checkbox device @your_host``.
 
-Note that if the Daemon is enabled, the Slave will go back up after a reboot.
+Note that if the Daemon is enabled, the Device will go back up after a reboot.
 
 
 Troubleshooting
 ===============
 
 Whenever you have a problem with misbehaving daemon, it's advisable to start
-troubleshooting by restarting the host running the Slave.
+troubleshooting by restarting the host running the Device.
 
-Daemon looks enabled but I cannot connect to it from the master
+Daemon looks enabled but I cannot connect to it from the remote
 ---------------------------------------------------------------
 
 Check if the daemon is enabled:
 
 .. code-block:: bash
 
-    $ snap get checkbox-snappy slave
+    $ snap get checkbox-snappy service
 
 Check if the service is enabled:
 
@@ -81,15 +81,15 @@ The output should state it's ``active (running)``.
 
 If it's not running, make sure the service and the Daemon are enabled.
 
-Master connects but I'm seeing wrong test plans
+Remote connects but I'm seeing wrong test plans
 -----------------------------------------------
 
 There is a chance that you have two services running that compete to listen
 on the default port.
 
-Try listing statuses of all Checkbox Slave services and make sure only one is
+Try listing statuses of all Checkbox Device services and make sure only one is
 running.
 
 .. code-block:: bash
 
-    $ sudo systemctl status '*checkbox*slave*'
+    $ sudo systemctl status '*checkbox*service*'