Skip to content

Decision Consumer Lifecycle (HyOps Module)

  • Purpose: Install the decision consumer that watches dispatch requests, waits for approval when required, and writes normalized execution records.
  • Trigger: Decision dispatcher is active and the control plane needs a separate approval-aware stage before any runner or future executor acts.
  • Impact: Installs a systemd service on the control host, monitors dispatcher requests, and writes execution records under the consumer state directory.
  • Severity: P1
  • Rollback strategy: Destroy the module state instance to remove the consumer service and its runtime directory.

Context

Module ref: platform/network/decision-consumer

This is the third control-plane stage:

  1. platform/network/decision-service emits a decision record.
  2. platform/network/decision-dispatcher converts it into a routed dispatch request.
  3. platform/network/decision-consumer waits for approval and writes an execution record.
  4. a later executor or runner-aware worker decides whether to run that record.

Current execution mode is intentionally conservative:

  • approval-only

That means the consumer never runs hyops directly. It only promotes approved requests into durable execution records.

Runtime paths on the control host:

  • dispatcher requests: /opt/hybridops/decision-dispatcher/state/requests
  • approval markers: /opt/hybridops/decision-consumer/state/approvals
  • execution records: /opt/hybridops/decision-consumer/state/executions
  • consumer state: /opt/hybridops/decision-consumer/state/state.json
  • consumer log: /opt/hybridops/decision-consumer/logs/consumer.log

Preconditions

  • the control host is reachable through the normal inventory/SSH contract
  • platform/network/decision-dispatcher is already installed and healthy
  • dispatcher requests carry target and execution-plane metadata
  • the approval process is defined for the environment

Execute

hyops apply --env dev \
  --module platform/network/decision-consumer \
  --inputs "$HOME/.hybridops/envs/dev/config/modules/platform__network__decision-consumer/latest.inputs.yml"

Verification

Check module outputs:

jq '.status, .outputs' \
  "$HOME/.hybridops/envs/dev/state/modules/platform__network__decision-consumer/latest.json"

Check live service state:

ssh -i "$HOME/.ssh/id_ed25519" opsadmin@5.161.116.216 \
  'sudo cat /opt/hybridops/decision-consumer/state/state.json'

Success indicators:

  • module state is status=ok
  • cap.control.decision_consumer = ready
  • decision_consumer.status = ready
  • decision_consumer.execution_mode = approval-only
  • the hyops-decision-consumer service is active

Synthetic approval validation

Use a disposable record chain to prove the full control-loop handoff without executing any workflow:

  1. write a synthetic decision record into the decision-service records directory
  2. wait for dispatcher to emit an awaiting-approval request
  3. write a matching approval marker under the consumer approvals directory
  4. wait one consumer poll cycle
  5. confirm an execution record appears under state/executions/
  6. remove the synthetic decision, request, approval marker, and execution record after verification

Observed live validation on the current dev control host:

  • source decision id: test-cutover-002
  • emitted dispatch id: dispatch-20260313T062802Z-cutover-5f868d84
  • approval marker: dispatch-20260313T062802Z-cutover-5f868d84.approved.json
  • emitted execution id: execution-20260313T062843Z-dispatch-20260313t062802z-cutover-5f868d84-fe5534a7
  • execution status: approved-ready
  • target: dr/postgresql-ha-failover-gcp@v1
  • execution plane: runner-local

This validation was executed and then cleaned back out of the live host so no fake pending request or execution record remained behind.

Destroy

hyops destroy --env dev \
  --module platform/network/decision-consumer \
  --inputs "$HOME/.hybridops/envs/dev/config/modules/platform__network__decision-consumer/latest.inputs.yml"

Notes

  • approval-only is the correct default while the executor layer is still being hardened.
  • Git remains the desired-state source for stateless workloads, not the incident trigger for DR or burst decisions.
  • The consumer should stay on the shared control host alongside the decision service and dispatcher, outside the primary on-prem failure domain.
  • A later executor may use the emitted execution records to drive hyops runner blueprint ... or another controlled execution plane.

References