Conditions for non-Fatal conditions

[mattmoor]

cc @n3wscott @sixolet @evankanderson @steren @cooperneil

tl;dr This issue proposes the introduction of new non-Fatal sub-conditions, which would NOT result in a change to the "happy condition" on changes. These would be suitable for non-Fatal warnings about the state of the resource.

Feedback welcome.

Background

Today, all subconditions contribute towards overall readiness, per errors.md:

• True when the reconciliation has succeeded. Once all transition conditions have succeeded, the "happy state" condition should be set to True.

To manage these conditions, we use a shared library (thanks @n3wscott ) that defines the following for managing the "happy" (e.g. Ready) condition based on the collective state of the rest:

	// MarkTrue sets the status of t to true, and then marks the happy condition to
	// true if all other dependents are also true.
	MarkTrue(t ConditionType)

	// MarkUnknown sets the status of t to Unknown and also sets the happy condition
	// to Unknown if no other dependent condition is in an error state.
	MarkUnknown(t ConditionType, reason, messageFormat string, messageA ...interface{})

	// MarkFalse sets the status of t and the happy condition to False.
	MarkFalse(t ConditionType, reason, messageFormat string, messageA ...interface{})

This inherently makes all of our sub-conditions what I'll call "Fatal".

Problems of Today

One of the places this bites us today is the Active condition, where we need to surface inactivity (so the Route can hook in the activator pre-stop until #1997 happens). The unfortunate side-effect of this is that the overall Revision reports Ready=False, which propagates to Configuration and Service:

  status:
    conditions:
    - lastTransitionTime: 2018-11-02T17:32:57Z
      message: The target is not receiving traffic.
      reason: NoTraffic
      status: "False"
      type: Active
    - lastTransitionTime: 2018-11-02T17:11:37Z
      status: "True"
      type: BuildSucceeded
    - lastTransitionTime: 2018-11-02T17:11:42Z
      status: "True"
      type: ContainerHealthy
    - lastTransitionTime: 2018-11-02T17:32:57Z
      message: The target is not receiving traffic.
      reason: NoTraffic
      status: "False"
      type: Ready
    - lastTransitionTime: 2018-11-02T17:11:42Z
      status: "True"
      type: ResourcesAvailable

One can imagine other scenarios where surfacing a warning is preferable to an outright failure state.

Proposal

I propose that we relax the requirement that all sub-conditions (potentially) trigger happy-state changes, and partition the sub-conditions of a type as follows:

• "Fatal" conditions: If a particular condition is one of these, then it participates in readiness as today.
• "non-Fatal" conditions (aka "Warnings"): If a particular condition is one of these, then it will not effect readiness at all, and is purely informational.

With this, the Revision status above would change to:

  status:
    conditions:
    - lastTransitionTime: 2018-11-02T17:32:57Z
      message: The target is not receiving traffic.
      reason: NoTraffic
      status: "False"
      type: Active
    - lastTransitionTime: 2018-11-02T17:11:37Z
      status: "True"
      type: BuildSucceeded
    - lastTransitionTime: 2018-11-02T17:11:42Z
      status: "True"
      type: ContainerHealthy
    - lastTransitionTime: 2018-11-02T17:11:42Z
      status: "True"
      type: Ready
    - lastTransitionTime: 2018-11-02T17:11:42Z
      status: "True"
      type: ResourcesAvailable

[n3wscott]

looks good to me

It might be nice to add something like log level to the condition?

  status:
    conditions:
    - lastTransitionTime: 2018-11-02T17:32:57Z
      message: The target is not receiving traffic.
      reason: NoTraffic
      status: "False"
      role: "informative"
      type: Active
    - lastTransitionTime: 2018-11-02T17:11:37Z
      status: "True"
      type: BuildSucceeded
    - lastTransitionTime: 2018-11-02T17:11:42Z
      status: "True"
      type: ContainerHealthy
    - lastTransitionTime: 2018-11-02T17:11:42Z
      status: "True"
      type: Ready
    - lastTransitionTime: 2018-11-02T17:11:42Z
      status: "True"
      type: ResourcesAvailable

default role or no role == main line happy or fatal condition.

[mattmoor]

@n3wscott My bias is to not, since these are a straight copy from the K8s API Principles.

[sixolet]

Can we call them "terminal" and "non-terminal"?

I nominate that (conventionally) terminal conditions end in Ready (or possibly Succeeded too), like RoutesReady. I'd like to be able to tell the difference at a glance, if possible.

[mattmoor]

@sixolet I think this is difficult until we have API versioning (cc @jonjohnsonjr )

[sixolet]

Oh, as in we already have conditions we want to be terminal named random other things you mean? Yeah, maybe "going forward we do this"?

What other ways might we have of seeing at a glance which conditions are terminal? We can't add a field (the condition schema comes from k8s)

I don't think I want to write code to depend on the names of conditions, I just want my brain to be able to sort them pleasantly.

[mattmoor]

as in we already have conditions we want to be terminal named random other things you mean?

Exactly.

I don't think I want to write code to depend on the names of conditions

I'm curious if/how the influence of the subcondition on the Ready condition is useful/relevant for the client to know? I think that in the most interesting cases for warnings, a condition turns False, but doesn't turn Ready=False.

I am curious what patterns you are thinking about that might not fit this naive mold?

[n3wscott]

The proposal given was suppose to be how conditions worked but I think it just has a bug.

[mattmoor]

@n3wscott I have a fix :)