rosotacom-dev 2.5.dev8__tar.gz → 2.5.dev12__tar.gz

{rosotacom_dev-2.5.dev8 → rosotacom_dev-2.5.dev12}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: rosotacom-dev
-Version: 2.5.dev8
+Version: 2.5.dev12
 Summary: Host CLI for ROS OTA communication sessions.
 Author: develNor
 License-Expression: BSD-3-Clause
@@ -439,7 +439,11 @@ rosotacom ota-smoke 2_native_chatter \
 
 `ota-smoke` accepts sessions and scenarios. It puts rosotacom on each peer,
 stages the active project, runs delivery and isolation checks, collects
-artifacts, stops the run, and removes the remote workdir. Add `--interactive`
+artifacts, stops the run, and removes the remote workdir. For scenario targets
+the checks start only once every declared application container is running
+(bounded at 10 minutes, covering a cold peer's first image build); an
+application that never comes up fails the run by name instead of as missing
+publishers. Add `--interactive`
 for a local control tmux with
 one attachable communication/catmux window per peer with a live status pane below
 each one. Scenario targets also get one native application-container window per
@@ -494,6 +498,34 @@ in this mode — there is no staging to undo, and the workdir is your repository
 The run manifest records which mode and which version the peers ran, so a result
 can be attributed to an artefact rather than to a working copy.
 
+#### How the peers are reached: `--peer-exec`
+
+`--peer-ssh` gives the orchestrator a shell on the peer, which is more than a
+run needs and more than some machines should hand out. `--peer-exec` names the
+transport instead:
+
+```bash
+rosotacom ota-smoke 2_native_chatter --peer a=workstation --peer b=robot \
+  --install-mode checkout \
+  --peer-checkout a=/home/me/fleet_mgmt --peer-checkout b=/home/robot/fleet_mgmt \
+  --peer-exec b='remote-rosotacom robot'
+```
+
+The command is run with the script as its final argument — the contract
+`ssh host <script>` already has — so anything of that shape can carry a peer: a
+wrapper that logs what a run asks for, a container exec, or a forced command
+that accepts some scripts and refuses the rest. rosotacom does not know or care
+which; it only stops assuming that reaching a peer means having a shell on it.
+
+Two restrictions, both load-bearing. It applies to `--install-mode checkout`
+only, because the staging modes push a tar stream and a file write by taking
+the ssh client's own argv apart, and a transport that promises no more than
+"run this script" cannot carry them. And a peer takes either `--peer-ssh` or
+`--peer-exec`, never both: leaving it ambiguous hides which one carried the run.
+
+`-t` and `-o BatchMode=yes` are dropped rather than forwarded. They are options
+of one client, and a transport that is not ssh never agreed to understand them.
+
 ### Live status / debugging overview
 
 Enable a continuously-updated, per-topic pipeline overview by setting

{rosotacom_dev-2.5.dev8 → rosotacom_dev-2.5.dev12}/README.md

@@ -394,7 +394,11 @@ rosotacom ota-smoke 2_native_chatter \
 
 `ota-smoke` accepts sessions and scenarios. It puts rosotacom on each peer,
 stages the active project, runs delivery and isolation checks, collects
-artifacts, stops the run, and removes the remote workdir. Add `--interactive`
+artifacts, stops the run, and removes the remote workdir. For scenario targets
+the checks start only once every declared application container is running
+(bounded at 10 minutes, covering a cold peer's first image build); an
+application that never comes up fails the run by name instead of as missing
+publishers. Add `--interactive`
 for a local control tmux with
 one attachable communication/catmux window per peer with a live status pane below
 each one. Scenario targets also get one native application-container window per
@@ -449,6 +453,34 @@ in this mode — there is no staging to undo, and the workdir is your repository
 The run manifest records which mode and which version the peers ran, so a result
 can be attributed to an artefact rather than to a working copy.
 
+#### How the peers are reached: `--peer-exec`
+
+`--peer-ssh` gives the orchestrator a shell on the peer, which is more than a
+run needs and more than some machines should hand out. `--peer-exec` names the
+transport instead:
+
+```bash
+rosotacom ota-smoke 2_native_chatter --peer a=workstation --peer b=robot \
+  --install-mode checkout \
+  --peer-checkout a=/home/me/fleet_mgmt --peer-checkout b=/home/robot/fleet_mgmt \
+  --peer-exec b='remote-rosotacom robot'
+```
+
+The command is run with the script as its final argument — the contract
+`ssh host <script>` already has — so anything of that shape can carry a peer: a
+wrapper that logs what a run asks for, a container exec, or a forced command
+that accepts some scripts and refuses the rest. rosotacom does not know or care
+which; it only stops assuming that reaching a peer means having a shell on it.
+
+Two restrictions, both load-bearing. It applies to `--install-mode checkout`
+only, because the staging modes push a tar stream and a file write by taking
+the ssh client's own argv apart, and a transport that promises no more than
+"run this script" cannot carry them. And a peer takes either `--peer-ssh` or
+`--peer-exec`, never both: leaving it ambiguous hides which one carried the run.
+
+`-t` and `-o BatchMode=yes` are dropped rather than forwarded. They are options
+of one client, and a transport that is not ssh never agreed to understand them.
+
 ### Live status / debugging overview
 
 Enable a continuously-updated, per-topic pipeline overview by setting