Hello Pico Fleet (Wrangler)
See the Open Engineering Language Server (OELS) onboarding guide for the local install and editor setup.
While you work through this content, keep the Open Engineering Language Server (OELS) active in VS Code (or any LSP-capable editor). See the OELS onboarding guide linked at the top of this page (also linked from the academy Resources page) for the one-time install and configuration steps.
What OELS validates. OELS only recognizes OE-shaped YAML/JSON: files with a mapping root that declare an apiVersion beginning with open-engineering.io/, a non-empty kind, and a DNS-1123 metadata.name. Ordinary academy metadata.yaml, Quarto/QMD pages and front matter, Kubernetes/Crossplane/runtime manifests, JSON payload samples, and shell scripts are intentionally non-OE — OELS ignores them silently and you should not add synthetic apiVersion/kind headers to force recognition.
Where you see diagnostics. OELS surfaces UnknownProperty, MissingRequiredProperty, IncorrectType, InvalidEnumValue, MalformedIdentifier, UnknownDefinition, and reference-shape hints in the editor Problems panel as you type. These are independent of quarto render: OELS diagnostics do not block rendering, and Quarto errors do not appear in the Problems panel.
The executable check still comes from this exercise. OELS speeds up editing, but the exercise’s own parser, verifier, or verify.sh (for example the pico parse … command shown below) remains the authoritative success check. Run it as usual.
Overview
Hello Pico Fleet (Wrangler) is the first topology and fleet path of the Open Engineering Academy. It layers a single Wrangler-authored Fleet fragment over the two already-approved Manifold InteractionTopologies:
- Hello Pico on Manifold lab (
hello-world-pico-on-manifold) and - Hello Two Picos lab (
hello-two-picos).
Wrangler here is the declarative topology/fleet authoring layer that sits above the runtime — it does not host Picos, it does not own the ontology, and it does not replace Kubernetes, Manifold, the Python CLI, or the Home Assistant control surface. It composes existing Wrangler-authored InteractionTopologies into one small fleet, attributes every named Pico back to its owning topology, records the channel bindings across the fleet, and expresses one fleet-level lifecycle intent.
This lab covers one Wrangler-authored fleet composed of two existing InteractionTopologies, three named Pico Elements, three channel bindings across two Channels, and one fleet-level lifecycle intent. Broader fleet orchestration, live reconciliation controllers, policy engines, multi-cluster fleets, non-Kubernetes runtimes, and any fleet path that bypasses the two underlying labs’ runtime manifests are explicitly out of scope. The Kubernetes substrate is kept fixed at local minikube throughout.
Structure
What you will produce
A single artifact directory named hello-pico-fleet containing:
- the authored Wrangler
fleet.yamlfragment, - the on-cluster
fleet-configmap.yamlcarrier as applied to the Manifold RuntimeEnvironment, and - the captured
kubectl get cm hello-pico-fleet -n manifold -o yamloutput confirming the fleet spec reached the cluster verbatim.
Downloads and screenshots
Starter files live under downloads/: the Wrangler fleet.yaml fragment, the ConfigMap carrier, and verify.sh — the offline shape verifier the walkthrough runs in its final step. Screenshots referenced from the walkthrough live under screenshots/. Both directories are kept even when empty so authors have a consistent place to add assets.
Metadata
Machine-readable descriptor: metadata.yaml. Fields follow the schema documented in the source repository under templates/README.qmd, including the Phase 7 fields runtime_substrate, runs_on, interaction_topology, and control_surfaces.
Constructive realization
This lab is the Realization of a small Wrangler fleet Definition consistent with the Phase 7 vocabulary in templates/README.qmd. The role mapping is:
- Definition (Phase 7 contract): Wrangler authors declarative
InteractionTopologyand fleet-level orchestration over a RuntimeEnvironment. A fleet composes existing InteractionTopologies, names the Pico Elements and Channel bindings it exposes, and records fleet-level lifecycle intent. It never becomes the runtime. - Realization (this lab): a
Fleetfragment onwrangler.oe.academy/v1alpha1that references the two approved Manifold InteractionTopologies, names three Picos and their bindings across two Channels, and declares one fleet-level lifecycle intent. A ConfigMap carries the fleet spec verbatim onto the same Kubernetes cluster the underlying labs use. - Element:
hello-pico-fleet— the captured fleet fragment, the applied ConfigMap, and the cluster read-back that confirms the fleet spec is present on the RuntimeEnvironment.
Referenced from
- Hello Pico on Manifold lab — the first member InteractionTopology of the fleet.
- Hello Two Picos lab — the second member InteractionTopology of the fleet.
- Manifold course — the runtime-focused course whose scope explicitly excludes fleet orchestration; this lab is the follow-up path that adds one, narrowly.