Improve `Status` on the Team Operator Resources

[ian-flores]

We should update the Status to have useful information. For instance:

• The version of the product in question
• "Readiness" stages...? i.e. once the deployment is happy
• A way to test connectivity or health...?

Other ideas? Maybe check out other operators internally for ideas

---

Migrated from rstudio/ptd#961

[ian-flores]

@claude can we clarify this issue or expand on it?

[claude]

Claude finished @ian-flores's task —— View job

---

Analysis: Improve Status on Team Operator Resources

• Examine current Status definitions in CRD/API types
• Review how status is set/updated in controllers
• Look at other operators for best practices
• Provide expanded issue clarification with concrete recommendations

---

Current State

The status implementation is minimal across all CRDs:

Resource	Status Fields	Status Updates in Controller
Site	Empty struct	None
Connect	Ready bool, KeySecretRef	Sets Ready=true on successful reconcile
Workbench	Ready bool, KeySecretRef	Sets Ready=true on successful reconcile
PackageManager	Ready bool, KeySecretRef	Sets Ready=true on successful reconcile
Chronicle	Ready bool	Sets Ready=true on successful reconcile
Flightdeck	Ready bool	Never updated
PostgresDatabase	Empty struct	None
Keycloak	Empty struct	None

Key problems:

• Ready is only ever set to true — never set back to false on failures
• No error reporting through status
• No progress tracking during reconciliation
• Existing TODO comments in controllers (// TODO: should we watch for happy pods?) acknowledge this gap
• Documentation already references status.conditions (e.g., upgrading.md:159) but conditions don't exist yet

---

Recommended Improvements

This issue could be broken into the following sub-tasks:

1. Add Standard metav1.Condition Support (High Priority)

Add a Conditions []metav1.Condition field to all Status structs. This is the standard Kubernetes pattern (used by Deployments, Jobs, etc.) and enables kubectl wait --for=condition=.... Suggested condition types:

Condition Type	Meaning
Ready	Resource is fully reconciled and operational
Progressing	Reconciliation is in progress
Degraded	Resource exists but is not fully healthy
Available	Underlying deployment is serving traffic

Use meta.SetStatusCondition() from apimachinery/pkg/api/meta for atomic condition updates.

2. Add ObservedGeneration (High Priority)

ObservedGeneration int64 `json:"observedGeneration,omitempty"`

This is critical for detecting whether the controller has processed the latest spec changes. Without it, there's no way to distinguish "not yet reconciled" from "reconciled successfully."

3. Add Product Version Tracking (Medium Priority)

Version string `json:"version,omitempty"`

Track the actual running version of each product (Connect, Workbench, PackageManager). This can be derived from the container image tag. Useful for auditing and upgrade verification.

4. Add Deployment Health Propagation (Medium Priority)

Reflect the actual Deployment/StatefulSet status back to the CRD status:

ReadyReplicas   int32 `json:"readyReplicas,omitempty"`
DesiredReplicas int32 `json:"desiredReplicas,omitempty"`

This addresses the existing // TODO: should we watch for happy pods? comments in connect.go:113, workbench.go:144, and package_manager.go:183.

5. Add Site-Level Aggregate Status (Medium Priority)

The SiteStatus is currently empty. It should aggregate the status of all child resources:

type SiteStatus struct {
    ObservedGeneration int64              `json:"observedGeneration,omitempty"`
    Conditions         []metav1.Condition `json:"conditions,omitempty"`
    Components         []ComponentStatus  `json:"components,omitempty"`
}

type ComponentStatus struct {
    Name  string `json:"name"`
    Ready bool   `json:"ready"`
    // ...
}

6. Set Status on Failures (High Priority)

Currently, if reconciliation errors out, status is never updated — Ready stays true from the last success. Controllers should set Ready=false and record the error in a condition when reconciliation fails.

7. Add Health/Connectivity Endpoint Info (Low Priority)

Endpoint string `json:"endpoint,omitempty"`

Expose the URL/endpoint for each product so users can quickly find where products are accessible.

---

Suggested Sub-Issues

I'd recommend splitting this into these issues:

1. Add Conditions and ObservedGeneration to all Status structs (items 1, 2)
2. Update controllers to set conditions on success and failure (item 6)
3. Propagate deployment health to CRD status (items 3, 4)
4. Add aggregate Site status (item 5)
5. Add endpoint/URL to product status (item 7)

---

| Branch: claude-issue-25-20260210-1622