Workshop updates

.github/workflows/gh-pages.yml

@@ -27,4 +27,4 @@ jobs:
         run: ./setup_subprojects.sh
 
       - name: Build and deploy
-        run: uv run --no-sync mkdocs gh-deploy --force
+        run: uv run --no-sync mkdocs gh-deploy --force --strict

.github/workflows/run-mkdocs-build.yml

@@ -0,0 +1,29 @@
+name: Test mkdocs build
+
+on:
+  pull_request:
+    branches: ["main"]
+
+env:
+  UV_LOCKED: true # Assert that the `uv.lock` will remain unchanged
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+
+      - name: Install uv and set the python version
+        uses: astral-sh/setup-uv@v8.2.0
+        with:
+          # It is considered best practice to pin to a specific uv version.
+          version: "0.11.26"
+
+      - name: Install site dependencies
+        run: uv sync
+
+      - name: Set up subprojects
+        run: ./setup_subprojects.sh
+
+      - name: Test mkdocs build with --strict
+        run: DISABLE_MKDOCS_2_WARNING=true uv run --no-sync mkdocs build --strict

docs/workshops/example-orchestrator/bootstrap.md

@@ -1,24 +1,101 @@
 # Bootstrapping the environment
 
+This section describes how you can run the orchestrator-core, orchestrator-ui, and netbox with Docker Compose. We have this all
+setup in our docker-compose.yml file so that you don't have to think about how to start the applications required for this workshop!
 
-Here is how you can run the orchestrator-core, orchestrator-ui, and netbox with Docker Compose. We have this all
-setup in our docker-compose.yml file so that you don't have to think about how to start the applications required for this workshop! If you want to read more about how to manually install the Workflow Orchestrator, please refer to [the beginner workshop here](../beginner/debian.md). The following Docker images are used in this workshop:
+The following Docker images are used in this workshop:
 
 * [orchestrator-core](https://github.com/workfloworchestrator/orchestrator-core/pkgs/container/orchestrator-core): The workflow orchestrator step engine.
-* [orchestrator-ui](https://github.com/workfloworchestrator/orchestrator-ui/pkgs/container/orchestrator-ui): The
-  GUI for the orchestrator-core.
-* [netbox](https://docs.netbox.dev/en/stable/): A free IPAM and SoT system.
+* [example-orchestrator-ui](https://github.com/workfloworchestrator/example-orchestrator-ui/pkgs/container/example-orchestrator-ui): An example GUI implementation for the orchestrator-core.
+* [netbox](https://docs.netbox.dev/en/stable/): An open source IPAM and NSoT system.
 * [postgres](https://hub.docker.com/_/postgres): The PostgreSQL object-relational database system.
-* [redis](https://redis.io/): An open source, in-memory data store used by netbox
-* Optional: [containerlab](https://containerlab.dev/): A free network topology simulator that uses containerized
-  network operating systems.
+* [redis](https://redis.io/): An open source in-memory data store.
+* [containerlab](https://containerlab.dev/): A free network topology simulator that uses containerized
+  Network Operating Systems.
 
-!!! danger
-    **To run the workshop with container lab, the host architecture must be x86_64 with virtualization
-    enabled**
+## Prerequisites
+
+The following software is required on your machine to follow this workshop:
+
+- [docker-compose](https://docs.docker.com/compose/install/)
+- [containerlab](https://containerlab.dev/install/)
+
+
+### macOS on Apple Silicon
+
+!!! note
+    This only applies to **ARM / Apple Silicon (M-series) Macs**. On Linux and
+    Intel machines a standard Docker install works — skip to
+    [Step 1](#step-1-cloning-the-repo).
+
+**Docker runtime (colima + virtiofs).**
+On Apple Silicon the containerlab SR Linux nodes need a Docker VM that mounts host
+paths with **virtiofs** and has enough memory. The default Docker Desktop VM and
+colima's legacy `sshfs` mount both break the nodes in two ways:
+
+- **`virtiofs`, not `sshfs`.** SR Linux generates a TLS keypair at boot and
+  `chown`s it. `sshfs` forbids `chown` even as root, so the keygen fails,
+  `sr_linux_mgr` crash-loops, and no management server (JSON-RPC / gNMI / gRPC)
+  ever comes online.
+- **≥ 8 GB VM memory.** Each SR Linux node reserves ~2 GB; on a smaller VM the
+  kernel OOM-killer keeps killing `sr_mgmt_server` and the nodes never settle.
+
+Use [colima](https://github.com/abiosoft/colima) as the Docker runtime:
+
+```shell
+brew install colima docker
+
+# vm-type vz + virtiofs is the Apple Silicon path; 8 GB / 4 CPUs runs the
+# compose stack and the 3-node lab together.
+colima start --vm-type vz --mount-type virtiofs --memory 8 --cpu 4
+```
+
+Confirm the VM before continuing:
+
+```shell
+colima status | grep mountType   # -> mountType: virtiofs
+colima ssh -- free -h            # Mem total should be ~8 GB
+```
+
+!!! danger "Do not run Docker Desktop at the same time as colima"
+    Both register a `docker` CLI context and fight over the `/var/run/docker.sock`
+    symlink and host ports, leaving you with a broken, non-deterministic Docker
+    setup. Quit Docker Desktop (and disable "Start at login") before using colima.
+
+!!! warning "`mountType` / `vmType` are fixed when the VM is created"
+    The `--mount-type` / `--vm-type` flags are silently ignored on an existing VM.
+    If your colima VM was created with `sshfs`, recreate it — this destroys the
+    VM's containers, images and volumes:
+
+    ```shell
+    colima delete && colima start --vm-type vz --mount-type virtiofs --memory 8 --cpu 4
+    ```
+
+    Memory and CPU, by contrast, *can* be changed on a plain restart:
+    `colima stop && colima start --memory 8 --cpu 4`.
+
+Once the runtime is up, run the `containerlab` commands in this guide from the
+maintainers' container — there is no native `containerlab` binary on Apple Silicon:
+
+!!! info
+    For MacOS ARM there is no `containerlab` executable.
+    You can run the `containerlab` commands in this guide from within this container provided by the maintainers.
+        ```shell
+        docker run --rm -it --privileged \
+        --network host \
+        -v /var/run/docker.sock:/var/run/docker.sock \
+        -v /var/run/netns:/var/run/netns \
+        -v /var/lib/docker/containers:/var/lib/docker/containers \
+        --pid="host" \
+        -v $(pwd):$(pwd) \
+        -w $(pwd) \
+        ghcr.io/srl-labs/clab bash
+        ```
 
 ## Step 1 - Cloning the repo
+
 The fist step is to clone the Example orchestrator repository using:
+
 ```
 git clone https://github.com/workfloworchestrator/example-orchestrator.git
 ```
@@ -30,128 +107,140 @@ At this point, you have a functional environment to start play with. This includ
 * An example containerlab topology based on Nokia SRlinux.
 * Some examples of Ansible playbooks
 
-The directory structure looks like this:
+The directory contains at least these files and directories:
+
 ```
-~/example-orchestrator# ls -la
-total 144
-drwxr-xr-x 14 root root  4096 May 10 10:29 .
-drwx------ 16 root root  4096 May 15 06:42 ..
--rw-r--r--  1 root root   147 May  8 10:35 .env.example
-drwxr-xr-x  8 root root  4096 May 15 10:15 .git
--rw-r--r--  1 root root    82 May  8 10:56 .gitignore
-drwxr-xr-x  2 root root  4096 May  8 10:35 .pictures
--rw-r--r--  1 root root 50000 May  8 10:56 README.md
--rw-r--r--  1 root root   884 May  8 10:35 alembic.ini
-drwxr-xr-x  4 root root  4096 May  9 19:42 ansible <<<< Ansible playbooks
-drwxr-xr-x  3 root root  4096 May 15 10:16 clab <<<< Containerlab topology
-drwxr-xr-x  9 root root  4096 May  8 10:56 docker <<<< Docker folder for config etc..
--rw-r--r--  1 root root  4469 May 10 10:29 docker-compose.yml <<<< The docker compoose file to spin up orchestrator stack
--rw-r--r--  1 root root   920 May  8 10:35 main.py
-drwxr-xr-x  3 root root  4096 May  8 10:35 migrations
-drwxr-xr-x  5 root root  4096 May  8 10:56 products
--rw-r--r--  1 root root   100 May  8 10:35 pyproject.toml
--rw-r--r--  1 root root    41 May  8 10:35 requirements.txt
-drwxr-xr-x  2 root root  4096 May 10 10:46 services
--rw-r--r--  1 root root   942 May  8 10:35 settings.py
-drwxr-xr-x  2 root root  4096 May  8 10:35 templates
-drwxr-xr-x  2 root root  4096 May  8 10:35 translations
-drwxr-xr-x  2 root root  4096 May  8 10:35 utils
-drwxr-xr-x  7 root root  4096 May  8 10:56 workflows
+$ ls -1
+alembic.ini
+ansible
+clab
+db
+docker
+docker-compose.yml
+main.py
+migrations
+products
+README.md
+services
+settings.py
+templates
+translations
+utils
+workflows
+wsgi.py
 ```
 
-## Step 2 - Editing the environment
-Before starting up the stacks, we have to check the file:
+## Step 2 - Preparing the environment
 
-```
-docker/orchestrator-ui/orchestrator-ui.env
-```
+**Check port availability**
 
-and adjust the LISTENING_IP value:
+The environment requires several ports to be free.
+Use the command matching your OS to check if any are in use.
+
+On Linux you can use `netstat` or `ss`:
 
 ```
-ENVIRONMENT_NAME="Example Orchestrator"
+# net-tools
+netstat -tulnp | grep -E ':80|:3000|:4000|:5432|:5678|:8000|:8001|:8080'
 
-ORCHESTRATOR_API_HOST=http://<$LISTENING_IP>:8080
-ORCHESTRATOR_API_PATH=/api
-ORCHESTRATOR_GRAPHQL_HOST=http://<$LISTENING_IP>:8080
-ORCHESTRATOR_GRAPHQL_PATH=/api/graphql
-NEXTAUTH_SECRET=ToDo
+# iproute2
+ss -tulnp | grep -E ':80|:3000|:4000|:5432|:5678|:8000|:8001|:8080'
 ```
-* if you are running the orchestrator locally, for example on your laptop, use "localhost"
-* if you are running the orchestrator on a remote machine, use the IP of that machine, for example 1.2.3.4
 
-## Step 3 - Starting the environment
-Once you edited the file, you can start the docker environment with:
+On macOS:
 
-### Remote lab environment with LSO and Containerlab
 ```
-COMPOSE_PROFILES=lso docker compose up
+lsof -nP -iTCP -sTCP:LISTEN | grep -E ':80 |:3000 |:4000 |:5432 |:5678 |:8000 |:8001 |:8080 '
 ```
-This will also enable LSO, so network devices will be actually configured. If you don't want this, just use:
 
-### Local environment
+No output means that all required ports available.
+Otherwise, track down and stop the corresponding processes before continuing.
 
-The environment requires several ports to be free.
-Use either command below to check if any are in use. No output means they're available:
+**Setup variables**
 
+Load the required environment variables:
+
+```shell
+source .env.workshop
 ```
-netstat -tulnp | grep -E ':80|:3000|:4000|:5432|:5678|:8000|:8001|:8080'
-ss -tulnp|grep -E ':80|:3000|:4000|:5432|:5678|:8000|:8001|:8080'
-```
 
-Start the containers:
+**Pull and build images**
+
+Just in case you have any of the docker images cached on your machine we'll explicitly pull and build them.
 
+```shell
+docker compose pull
+docker compose build
 ```
+
+## Step 3 - Starting the environment
+
+Now we can start the containers:
+
+```shell
 docker compose up -d
 ```
 
-and you should be able to view the
-applications here:
-
-If you are using your laptop:
+You should be able to view the applications here:
 
 1. Orchestrator ui: [Frontend: http://localhost:3000](http://localhost:3000)
-2. Orchestrator backend: [REST api: http://localhost:8080/api/redoc](http://localhost:8080/api/redoc) and  
-   [Graphql API: http://localbost:8080/api/graphql](http://localbost:8080/api/graphql)
+2. Orchestrator backend: [REST api: http://localhost:8080/api/redoc](http://localhost:8080/api/redoc) and
+   [Graphql API: http://localbost:8080/api/graphql](http://localhost:8080/api/graphql)
 3. Netbox (admin|admin): [Netbox: http://localhost:8000](http://localhost:8000)
 
-If you are using a remote machine:
+!!! note
+    Take your time to familiarise with the applications and make sure they are working correctly.
 
-1. Orchestrator ui: Frontend: http://<$IP_ADDRESS_OF_THE_MACHINE>:3000
-2. Orchestrator backend: REST api: http://<$IP_ADDRESS_OF_THE_MACHINE>:8080/api/redoc
-   Graphql API: http://<$IP_ADDRESS_OF_THE_MACHINE>:8080/api/graphql
-3. Netbox (admin|admin): Netbox: http://<$IP_ADDRESS_OF_THE_MACHINE>:8000
+    If anything is wrong, inspect the results of these commands:
 
-!!! note
-    Take your time to familiarise with the applications and make sure they are working correctly. You can then
-    continue with the following steps.
+    ```shell
+    # Check the status of all services
+    docker compose ps
+
+    # Follow the logs of all services
+    # It can be helpful to keep this command running in a separate terminal
+    docker compose logs -tf -n 5
+    ```
+
+## Step 4 - Containerlab
 
-## Optional: Step 4 Containerlab
 Now that we have our orchestrator stack running, we can spin up the containerlab topology:
 
 ```
 cd clab
 containerlab deploy
 ```
+
 At the end of this process we can use `containerlab inspect` to check the status of our topology:
 
 ```
-~/example-orchestrator/clab# containerlab inspect
-INFO[0000] Parsing & checking topology file: srlinux01.clab.yaml
-+---+-----------------------+--------------+-----------------------+------+---------+----------------+--------------+
-| # |         Name          | Container ID |         Image         | Kind |  State  |  IPv4 Address  | IPv6 Address |
-+---+-----------------------+--------------+-----------------------+------+---------+----------------+--------------+
-| 1 | clab-orch-demo-ams-pe | 46ddee7df745 | ghcr.io/nokia/srlinux | srl  | running | 172.22.0.11/16 | N/A          |
-| 2 | clab-orch-demo-lon-pe | fe3f5d6eb35e | ghcr.io/nokia/srlinux | srl  | running | 172.22.0.10/16 | N/A          |
-| 3 | clab-orch-demo-par-p  | 4831968e075c | ghcr.io/nokia/srlinux | srl  | running | 172.22.0.9/16  | N/A          |
-+---+-----------------------+--------------+-----------------------+------+---------+----------------+--------------+
+╭───────────────────────┬──────────────────────────────┬─────────┬────────────────╮
+│          Name         │          Kind/Image          │  State  │ IPv4/6 Address │
+├───────────────────────┼──────────────────────────────┼─────────┼────────────────┤
+│ clab-orch-demo-ams-pe │ srl                          │ running │ 172.18.0.12    │
+│                       │ ghcr.io/nokia/srlinux:25.7.1 │         │ N/A            │
+├───────────────────────┼──────────────────────────────┼─────────┼────────────────┤
+│ clab-orch-demo-lon-pe │ srl                          │ running │ 172.18.0.11    │
+│                       │ ghcr.io/nokia/srlinux:25.7.1 │         │ N/A            │
+├───────────────────────┼──────────────────────────────┼─────────┼────────────────┤
+│ clab-orch-demo-par-p  │ srl                          │ running │ 172.18.0.13    │
+│                       │ ghcr.io/nokia/srlinux:25.7.1 │         │ N/A            │
+╰───────────────────────┴──────────────────────────────┴─────────┴────────────────╯
 ```
 
+!!! info
+    You will see a few deprecation notices about type `ixrd2` being deprecated, you can ignore this.
+
 And with the command:
+
 ```
 containerlab graph
 ```
-we can have a nice rendering of the topology served on port 50080 (for example https://localhost:50080).
+
+This will serve a nice rendering of the topology on port [50080](http://localhost:50080).
+
+!!! info
+    When using containerlab's docker image, this does not work.
 
 The topology we are going to use is something like this one:
 
@@ -170,10 +259,18 @@ We can start feeding initial data into the environment and run some workflows!
 
 ### Resetting Your Environment
 
-To reset the active state of your environment back to scratch, simply use docker compose to delete volumes, like so:
+To completely reset your environment and start from scratch, follow these steps.
+
+If you had containerlab deployed, destroy the deployed nodes:
+
+```shell
+containerlab destroy
+```
+
+Stop the docker compose stack and remove all volumes:
 
-```bash
-jlpicard@ncc-1701-d:~$ docker compose down -v
+```shell
+docker compose down -v
 ```
 
-You can then restart the containers as described above.
+You can then restart the environment as described above.

docs/workshops/example-orchestrator/create-your-own.md

@@ -5,5 +5,6 @@ Orchestrator provides the user. In this scenario you will create a product that
 L2VPN product, but constrained to two interfaces. In other words a L2 Point-to-Point circuit.
 
 ## L2 Point-to-Point model
+
 {{ external_markdown('https://raw.githubusercontent.com/workfloworchestrator/orchestrator-core/main/docs/architecture/product_modelling/l2_point_to_point.md',
 '') }}