Some checks are pending
Bidi Control Character Guard / bidi-control-guard (push) Waiting to run
Circular Dependency Check / Check for new circular dependencies (push) Waiting to run
Citus Migration Smoke / Combined migrations on single-node Citus (push) Waiting to run
E2E Fresh Install Tests / fresh-install-e2e (push) Waiting to run
ext-v2 guardrails / Run ext-v2 guard and ESLint (push) Waiting to run
Integration Tests / Check for relevant changes (push) Waiting to run
Integration Tests / ${{ (github.event_name == 'schedule' || github.event.inputs.suite == 'full') && 'Full integration suite' || 'Tier-1 integration subset' }} (push) Blocked by required conditions
Mobile checks / Mobile lint + typecheck (push) Waiting to run
Mobile checks / Mobile unit tests (push) Waiting to run
Mobile checks / Mobile dependency audit (report) (push) Waiting to run
Mobile checks / Mobile reproducibility checks (push) Waiting to run
Secrets guard (env backups) / Ensure no tracked env backup files (push) Waiting to run
Temporal Readiness / fast-readiness (push) Waiting to run
Temporal Readiness / docker-parity (push) Waiting to run
TypeScript Type Check / Nx affected typecheck (push) Waiting to run
Unit Tests / Skipped-test budget (push) Waiting to run
Unit Tests / Nx affected unit tests (push) Waiting to run
Unit Tests / Server unit coverage (informational) (push) Waiting to run
Validate Tenant Management Schema / Check for relevant changes (push) Waiting to run
Validate Tenant Management Schema / Validate Tenant Management Schema (push) Blocked by required conditions
EE Workflows Build Guard / ee-workflows-build-guard (push) Waiting to run
Excluded: .git, node_modules, secrets/, compose.env, assemblyscript tgz Source: /opt/alga-psa on psa.joliet.tech
2.0 KiB
2.0 KiB
Talos Support Bundles
Purpose
The first support posture for the Talos appliance is an exportable support bundle, not a persistent support tunnel.
That is a deliberate product boundary:
- the appliance must remain diagnosable in connected but tightly controlled environments
- support should not depend on live shell access
- the support surface should stay smaller than a remote-access platform
Support Model
The appliance should assume:
- customer environments are usually connected
- support may ask the customer to run one bundle collection command
- the resulting archive becomes the primary diagnostic artifact
This keeps support viable in environments where outbound tunnels are disallowed or heavily reviewed.
Minimum Bundle Contents
A useful appliance bundle should include:
- cluster version and node inventory
- node conditions and scheduling state
- storage classes, PVs, PVCs, and recent events
- Flux source,
Kustomization, andHelmReleasestatus - workload inventory for
flux-system,alga-system, andmsp - bootstrap job status and logs
- core application, database, and worker logs
- Talos node health and service state when a Talos context is available
The bundle is intended to answer the layered support question:
- is the failure at the Talos layer
- the Kubernetes/storage layer
- the GitOps layer
- or the application bootstrap/runtime layer
Secret Handling
The bundle should not export live secret payloads.
Safe defaults are:
- include secret names only
- include references to credentials used by workloads
- exclude raw
datavalues from KubernetesSecretobjects - avoid embedding raw Talos machine config when it contains cluster credentials
Operator Contract
Bundle collection must be predictable and low-friction.
The operator-facing contract should be:
- one stable command
- one generated archive
- no need to manually gather pod logs, describe output, and Talos checks piecemeal
That is what makes the appliance supportable for customers who are not Talos experts.