Define how HTTPProxy validity interacts with delegation

[jpeach]

trafficstars

HTTPProxy delegation can interact with validity in unexpected ways.

1. If proxy A delegates to proxy B, and proxy B is not present, then proxy A is marked invalid.
2. If proxy A delegates to B, but B is invalid for some reason, then B is marked invalid. A is considered valid, but lacks any routes that would have been imported by B.

If we consider a proxy with no routes (or TCP proxying) invalid as per #1988, then that can have the effect of bubbling errors up the delegation chain until the root proxy becomes invalid. Consider the case of A includes B, which includes C and D. If C and D are absent, then B will be invalid and A will subsequently have no routes. Similarly, if C and D both have errors, B will ve valid but have no routes, which means that A will also be valid and have no routes.

So we can see that defining a proxy with no routes as invalid has the undesirable property of propagating errors all the way up the delegation chain. This is because Contour's internal concept of valid/invalid doesn't align well with actual cases of partial or debatable validity.

Somewhat orthogonally to the concept of validity, we can consider what the corresponding Envoy configuration is for a proxy. Currently, it is reasonable to expect that if Contour marks a proxy as valid, then it will provision the corresponding Envoy resources. If a proxy has no routes, that's a problem that should be exposed through the API, However, if this state is tightly coupled to Envoy provisioning, as we described above, this could end up removing the Envoy vhost and even the corresponding listener. The implication of this is that propagating errors at the leaves of a delegation chain can cascade. what we really want is for Contour to limit the blast radius of configuration errors.

The status concepts described in #1868 can be helpful here, because applying conditions to the proxy status gives us a way to expose partial validity. If we can expose partial validity, then we can decouple that from the decision of whether to expose proxy resources into Envoy.

To resolve this issue, we should

• [ ] Document the principles for HTTPProxy delegation and error handling
• [ ] Document how HTTPProxy ought to expose Envoy resources in the presence of errors
• [ ] Evaluate moving to status conditions in order to make the documentation true

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack