jester/zlh-grind
1
0
Fork 0
Code Issues 14 Pull Requests Actions Packages Projects Releases Wiki Activity

Launch blocker: finalize patch management and maintenance window policy #7

New Issue
Open
opened 2026-05-02 23:38:10 +00:00 by jester · 0 comments
jester commented 2026-05-02 23:38:10 +00:00
Owner
Copy Link

Launch blocker

Finalize and document operational patch management and maintenance window policy before launch.

Why this blocks launch

Production needs a clear customer-facing and internal policy for when/how platform maintenance happens, what can be patched live, what requires downtime, and how customers are notified.

Required decisions

  • Define normal maintenance window cadence and timezone.
  • Define emergency maintenance behavior.
  • Define customer notification expectations for planned maintenance.
  • Define what maintenance can happen without workload shutdown vs what requires restart/shutdown.
  • Define patch ownership for:
    • Proxmox VE host
    • PBS / zlh-back
    • OPNsense routers
    • API / Portal VMs
    • game/dev container base templates
    • agent updates
    • Velocity / proxy edge
    • monitoring stack
  • Define rollback expectations if a patch/regression affects provisioning, networking, or customer workloads.

Validation needed

  • Confirm customer-facing maintenance messaging exists or is planned.
  • Confirm internal runbook exists for patch ordering and rollback.
  • Confirm maintenance state does not conflict with provisioning, backup, restore, or billing workflows.
  • Confirm emergency maintenance path is clear enough to execute without improvising.

Launch expectation

This does not need to be over-engineered, but the policy and first-run process must be clear before public launch.

## Launch blocker Finalize and document operational patch management and maintenance window policy before launch. ## Why this blocks launch Production needs a clear customer-facing and internal policy for when/how platform maintenance happens, what can be patched live, what requires downtime, and how customers are notified. ## Required decisions - Define normal maintenance window cadence and timezone. - Define emergency maintenance behavior. - Define customer notification expectations for planned maintenance. - Define what maintenance can happen without workload shutdown vs what requires restart/shutdown. - Define patch ownership for: - Proxmox VE host - PBS / zlh-back - OPNsense routers - API / Portal VMs - game/dev container base templates - agent updates - Velocity / proxy edge - monitoring stack - Define rollback expectations if a patch/regression affects provisioning, networking, or customer workloads. ## Validation needed - Confirm customer-facing maintenance messaging exists or is planned. - Confirm internal runbook exists for patch ordering and rollback. - Confirm maintenance state does not conflict with provisioning, backup, restore, or billing workflows. - Confirm emergency maintenance path is clear enough to execute without improvising. ## Launch expectation This does not need to be over-engineered, but the policy and first-run process must be clear before public launch.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: jester/zlh-grind#7
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?