OCPBUGS-29894: Check if CRLs are downloaded when determining ready status

[rfredette]

Require all CRLs to be downloaded before the router can report that it's ready. This prevents forwarding requests to a router until it's ready to handle mTLS.

This fixes OCPBUGS-29894

[openshift-ci-robot]

@rfredette: This pull request references Jira Issue OCPBUGS-29894, which is invalid:

• expected the bug to target the "4.16.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

Require all CRLs to be downloaded before the router can report that it's ready. This prevents forwarding requests to a router until it's ready to handle mTLS.

This fixes OCPBUGS-29894

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[rfredette]

/jira refresh

[openshift-ci-robot]

@rfredette: This pull request references Jira Issue OCPBUGS-29894, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.16.0) matches configured target version for branch (4.16.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @lihongan

In response to this:

/jira refresh

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[rfredette]

/retest

[Miciah]

/assign

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[lihongan]

/remove-lifecycle stale

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from miciah. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Miciah]

This makes a router pod start failing readiness checks if it has outdated CRLs, right?

To fix OCPBUGS-29894, it should be sufficient to fail readiness only for the initial synch, so that startup probes (which use the readiness endpoint) fail until the initial synch is done.

Once the router pod has done the initial synch, we want readiness checks to pass even if refresh fails, for two reasons:

• The expectation is to restore the behavior prior to OCPBUGS-6661, OCPBUGS-9464: Move mTLS CRL handling into the router, and fix accidental duplication of CRLs cluster-ingress-operator#939 and OCPBUGS-6661, OCPBUGS-9464: Handle mTLS CRLs, and fix accidental CRL duplication #472, and that behavior was to prevent a router pod from serving traffic until it had CRLs, not to prevent a router pod from serving traffic if it had outdated CRLs.
• It is generally less bad to continue using outdated CRLs, rather than to stop serving traffic entirely when refresh fails.

This does make me realize that we need a Prometheus metric and an alert when refresh fails for a prolonged period. Failure to refresh has two nasty implications:

• Router pods are using outdated CRLs.
• The next rolling update of the router deployment (for an upgrade, configuration change, or whatever reason) could get stuck as presumably the new pods would fail on initial synch.

[rfredette]

Once the router pod has done the initial synch, we want readiness checks to pass even if refresh fails

Ack, I'll update this so that the CRLs readiness check is only used for the initial sync.

This does make me realize that we need a Prometheus metric and an alert when refresh fails for a prolonged period.

That make sense, although I think that's out of the scope of this bug. I'll open a jira issue for that.

[rfredette]

e2e-upgrade failed during bootstrap.

/test e2e-upgrade

[openshift-ci]

@rfredette: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.