From 3a39a3794d12edd88571f6fff67a78c638127850 Mon Sep 17 00:00:00 2001 From: Jim Garlick Date: Fri, 6 Oct 2023 15:32:57 -0700 Subject: [PATCH] doc: add glossary references Problem: glossary terms are not referenced when used in guide documents. Reference them on first use in each document. --- doc/guide/interact.rst | 8 ++++---- doc/guide/start.rst | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/guide/interact.rst b/doc/guide/interact.rst index d9ce8d9fe6a5..22d6f63fdbdd 100644 --- a/doc/guide/interact.rst +++ b/doc/guide/interact.rst @@ -166,13 +166,13 @@ socket and looks something like:: local:///tmp/flux-lMDa6Z/local-0 -In the *initial program* (batch script, interactive alloc shell, or whatever), -the FLUX_URI environment variable is set to the local URI of the rank 0 -broker. Flux commands in the initial program, which also runs on rank 0, +In the :term:`initial program` (batch script, interactive alloc shell, or +whatever), the FLUX_URI environment variable is set to the local URI of the rank +0 broker. Flux commands in the initial program, which also runs on rank 0, read FLUX_URI and reference the instance that started them. When running outside of an instance, FLUX_URI will not be set. In this case, -commands fall back to the compiled-in URI of the Flux system instance. +commands fall back to the compiled-in URI of the Flux :term:`system instance`. When there isn't a broker of the system instance running on the local node, commands fail with an error like:: diff --git a/doc/guide/start.rst b/doc/guide/start.rst index 5f438af5388e..2a2c04ffd41d 100644 --- a/doc/guide/start.rst +++ b/doc/guide/start.rst @@ -22,7 +22,7 @@ parallel, as a *parallel program* if you will. phases: #. Initialize -#. The rank 0 broker runs the **initial program** to completion +#. The rank 0 broker runs the :term:`initial program` to completion #. Finalize By default, the initial program is an interactive shell. If :man1:`flux-start` @@ -280,8 +280,8 @@ can run Flux. No surprise there. What does that look like and how is it leveraged to provide expected workload manager abstractions? First let's try our workload commands in the "outer" Flux instance, in this -case a standalone system instance, although this section applies to all Flux -instances. +case a standalone :term:`system instance`, although this section applies to all +Flux instances. .. code-block:: console