govoplan-ops (0.1.19)
Installation
pip install --index-url https://git.add-ideas.de/api/packages/GovOPlaN/pypi/simple/ --extra-index-url https://pypi.org/simple govoplan-opsAbout this package
GovOPlaN operations module for health, deployment profile, and sizing visibility.
govoplan-ops
Repository type: module (platform).
GovOPlaN Ops provides the operator surface for deployment health, runtime profile visibility, worker split assumptions, and sizing guidance.
Ownership
This repository owns:
- backend module manifest
ops - operator-facing status APIs
- runtime-node registration, heartbeat, composition, stale-node, and expected replica projection
- queue-specific worker-pool coverage, release/composition skew, and the deployment-rendered PostgreSQL connection budget
- audited API and worker drain/cancel controls
- recovery-operation status and evidence-chain summaries
- sanitized, expiry-aware coordinated backup and isolated-restore status from the deployment verifier, without backup artifact or key-custody references
- governance inventory for module-declared permissions, roles, capabilities, policies, documentation, access-control hooks, search providers, and migration ownership
- sanitized runtime health, freshness, conflict, and recovery state for configured external-provider bindings
- deployment profile and sizing assumption summaries
- WebUI route contribution
@govoplan/ops-webui - future operational runbooks that describe the configured platform rather than generic product possibilities
Core owns lifecycle management, module discovery, maintenance mode, package installation safety, and shared WebUI shell behavior.
Core exposes the registry contract but does not own an operations dashboard. Ops projects the provider-neutral registry metadata and runtime checks into the operator-facing governance surface.
Provider declarations describe supported behavior; module-owned runtime-state providers describe the currently configured bindings. An optional provider failure is isolated and reported as an attention state without suppressing the rest of the governance inventory. Secrets, endpoints, and raw provider errors are not part of this projection.
Runbooks
docs/SCALABILITY_PROFILES.mdexplains how to use the Ops page with the canonical sizing matrix, readiness model, and profile-selection worksheet.
The Runtime cluster panel is backed by Core's shared PostgreSQL coordination
tables. A drain request is durable and is observed on the node heartbeat: API
readiness closes and workers stop taking new queue work. The Recovery panel
shows operations requiring forward recovery or manual intervention; it does not
claim that a production database backup exists.
For provider effects, Ops is the status and evidence-chain projection rather
than the reconciliation authority. Follow the owning module's bounded action:
for example, reconcile an unknown Mail SMTP command from provider evidence and
never retry the original effect merely because its caller state is incomplete.
For Dataflow, a database-only run is atomic. A published-output run is forward
recovery: inspect its recorded output digest and sink idempotency key, and do
not start another publication while its state is outcome_unknown.
For Workflow Engine, Ops exposes the action operation and evidence chain while
the Workflow handoff remains the reconciliation surface. Verify the provider,
then record Effect confirmed to continue without replay or Effect absent
to enable a deliberate retry. Instance, trigger-delivery, and timer leases show
which runtime currently owns transition authority across hosts.
For Core module lifecycle, the installer run record supplies the operation id.
Treat recovery_required and outcome_unknown as a deployment-wide stop: verify
the hashed package/database evidence, complete the declared rollback or forward
repair, and reconcile the operation before another install or live graph change.
The local installer lock is not a substitute for this database fence.