Define zones¶

Zones are how the Service Resource Manager (SRM) knows what it can deploy where. You declare them once in a bootstrap topology document: a tree of zone → domain → capability → control_path_binding, plus the control paths those bindings use to reach each backend. SRM loads that document through the TF-SDK discovery interface and seeds its database. Without a complete topology, application deploys have nowhere to go. Zone, domain, capability and control path are defined in the OOP Glossary.

On the example deployment that uses a kind cluster, environments/kind/values.yaml already ships one local zone. Use this guide when you define zones yourself — for example on another cluster, or when you add a remote edge site.

Before you start¶

• The Helm chart checkout (commands below are run from the helm directory), or the Ansible inventory that generates the same bootstrap. You can set topology on first install or on a later upgrade (Deploy with Helm, Deploy with Ansible).
• For each site: a zone ref and display name, and the domains and capabilities that site should expose.
• For each control path: the infrastructure settings (and any credential mounts) your adapter needs. Use the kind example and your adapter docs as the reference.

Steps¶

1. Declare control paths¶

Put the complete SDK bootstrap under srm.topology. This value is one YAML string: a later values file replaces the whole string. Keep all control paths and the complete zone tree together in the final file. Control paths are runtime-only: they build the adapter registry; the database stores bindings by control_path_ref.

Local cluster (SRM deploys into the same cluster it runs in):

srm:
  topology: |
    version: openop.srm.bootstrap/v1
    platform_instance_id: my-platform
    control_paths:
      - ref: k8s-local
        adapter_family: compute
        adapter_type: kubernetes
        adapter_contract_version: v1
        infrastructure:
          in_cluster: true
          namespace: oop-apps
    zones: []   # filled in the next step
  workloads:
    namespaces: [oop-apps]

Remote cluster: set kubeconfig_path, kube_context and namespace on the control path, and mount credentials with srm.controlPathCredentials (Secret must already exist in SRM's namespace). Details and validation rules are in the SRM chart README.

2. Declare the zone tree¶

Under zones:, add at least one resource zone and the domains/capabilities that site should expose. Bind each capability to a control path you declared above. Domain and capability kind values must match what that site offers and what the bound adapter can run.

Start from the local-cluster values example. It defines a zone where OpenOP can deploy application workloads on the same Kubernetes cluster as the platform. Replace endpoint_host: 192.0.2.10 with the node IP address that application clients use to reach NodePorts.

Every control_path_ref in a binding must match a control_paths[].ref. An unknown reference causes SRM startup to fail with InvalidTargetRef. Every ref must be unique across the whole bootstrap, not just within its zone; a repeated ref stops SRM from starting (duplicate … ref).

3. Allow workload namespaces¶

For in-cluster execution, set srm.workloads.namespaces to the workload namespaces on the platform cluster (oop-apps above). The chart grants SRM's ServiceAccount rights there and creates the namespaces when createNamespaces is true. An empty list generates no workload RBAC. For a remote control path, the mounted kubeconfig identity needs permissions on the remote cluster; this chart setting grants no remote rights.

4. Apply the values¶

Pass the platform's values files first and the complete topology values file last. For a concrete example on kind, use the chart's environments/kind/values.yaml as the platform configuration. Download the local-cluster values example into your Release 2 Helm checkout and adapt its node IP and topology, then run:

helm upgrade --install oop-platform ./oop-platform-chart \
  --kube-context PLATFORM_CONTEXT \
  -n oop --create-namespace \
  -f environments/kind/values.yaml \
  -f local-kubernetes.values.yaml

The downloaded local-kubernetes.values.yaml contains the complete bootstrap under srm.topology. For another environment, replace the kind values with that environment's platform values; for a remote workload backend, use the adapted remote-cluster example as the last file. When upgrading, use the existing platform release name, namespace and context, and include all platform values files required by your deployment. An upgrade that changes srm.topology restarts SRM.

If you deploy with Ansible, set oop_platform_bootstrap in the operator inventory. The role generates the bootstrap and credential mounts from that declaration; see Deploy with Ansible.

5. Optional: zone provider name¶

SRM reports a provider on each zone. Override the default (oop-provider) with:

srm:
  zoneProviderName: my-operator

Check it worked¶

Set OEG_URL to your platform's public OEG URL; the example below is for kind:

export OEG_URL=http://localhost:32263
# Obtain TOKEN as described in Get API access.
curl --fail-with-body -sS -H "Authorization: Bearer $TOKEN" \
  "$OEG_URL/edge-application-management/v0.1alpha1/edge-cloud-zones"

Use an App Provider token with edge-application-management:edge-cloud-zones:read; see Get API access.

You should see a JSON array that includes your zone (name and active state). An empty array usually means bootstrap did not seed, or SRM started with no topology.

If the list is empty or wrong, check bootstrap in the SRM logs:

kubectl --context PLATFORM_CONTEXT logs -n oop deploy/srmcontroller --tail=100 \
  | grep -iE 'bootstrap|topology|zone'

• Startup fails with InvalidTargetRef — a binding names a control path missing from control_paths. Fix the complete bootstrap and restart SRM.
• Deploys fail with "forbidden" — check the selected identity on the selected cluster. For in-cluster execution, check chart workload RBAC; for remote execution, check the kubeconfig user's remote permissions.

All options¶

Further reading:

• SRM chart README — bootstrap topology
• Helm README — install on another cluster (default install has no topology until you set one)
• Kubernetes integration — connecting a cluster as an edge cloud
• ADR-0059 — SRM seeds topology through TF-SDK discovery, not by parsing the file itself