This issue is focused specifically on status.conditions and not other parts of status that Service needs.
Expected Behavior
The Service controller should expose (at least) a status condition for Ready. However, to establish this it may also need RouteReady, and ConfigurationReady conditions, which means we need to watch those K8s resources for when they become ready.
An interesting question is whether it makes sense for us to have condition types specific to a particular class of rollout, e.g. runLatest vs. pinned.
- In the
runLatest case, I could see us wanting to surface LatestRevisionReady from the Configuration, so that folks know directly from Service whether a given update has taken effect.
- In the
pinned case, I could see us wanting to surface Ready from the the pinned revision, for similar reasons.
Actual Behavior
The Service resource doesn't currently set any conditions, which makes it impossible for clients to determine readiness.
This issue is focused specifically on
status.conditionsand not other parts ofstatusthatServiceneeds.Expected Behavior
The Service controller should expose (at least) a status condition for
Ready. However, to establish this it may also needRouteReady, andConfigurationReadyconditions, which means we need to watch those K8s resources for when they become ready.An interesting question is whether it makes sense for us to have condition types specific to a particular class of rollout, e.g.
runLatestvs.pinned.runLatestcase, I could see us wanting to surfaceLatestRevisionReadyfrom theConfiguration, so that folks know directly fromServicewhether a given update has taken effect.pinnedcase, I could see us wanting to surfaceReadyfrom the the pinned revision, for similar reasons.Actual Behavior
The Service resource doesn't currently set any conditions, which makes it impossible for clients to determine readiness.