the calico-apiserver namespace frequently get stuck for a long time in terminating status when upgrading to enterprise

[gcosgrave]

…

Description

The apiserver TigeraStatus error message Error creating / updating resource: secrets "tigera-apiserver-certs" is forbidden: unable to create new content in namespace calico-apiserver because it is being terminated identifies the problem as the certs secret is called "calico-apiserver-certs" when it is in the "calico-apiserver" namespace, and "tigera-apiserver-certs" when in the "tigera-apiserver" namespace

apiVersion: operator.tigera.io/v1
kind: TigeraStatus
metadata:
    creationTimestamp: "2024-07-18T11:15:59Z"
    generation: 1
    name: apiserver
    resourceVersion: "2010"
    uid: fcdb9846-3772-4684-afe3-db458486608b
spec: {}
status:
    conditions:
        - lastTransitionTime: "2024-07-18T11:18:06Z"
          message: 'Error creating / updating resource: secrets "tigera-apiserver-certs" is forbidden: unable to create new content in namespace calico-apiserver because it is being terminated'
          observedGeneration: 1
          reason: ResourceUpdateError
          status: "True"
          type: Degraded
        - lastTransitionTime: "2024-07-18T11:17:56Z"
          observedGeneration: 1
          reason: Unknown
          status: "False"
          type: Available
        - lastTransitionTime: "2024-07-18T11:17:56Z"
          message: Deployment "tigera-system/tigera-apiserver" is not available (awaiting 2 replicas)
          observedGeneration: 1
          reason: ResourceNotReady
          status: "True"
          type: Progressing

For PR author

• Tests for change.
• If changing pkg/apis/, run make gen-files
• If changing versions, run make gen-versions

For PR reviewers

A note for code reviewers - all pull requests must have the following:

• Milestone set according to targeted release.
• Appropriate labels:
  • kind/bug if this is a bugfix.
  • kind/enhancement if this is a a new feature.
  • enterprise if this PR applies to Calico Enterprise only.

[caseydavenport]

@tmjd @gcosgrave I think we still do need this check to handle the tiniest of race conditions.

If a user creates an Installation with no variant, we want to wait for the Installation / core controller to default it before we continue. It should only add a second of delay.

[tmjd]

Yeah I agree. To be specific the check can be changed to if installationSpec.Variant == ""

[gcosgrave]

done

[tmjd]

Looks good, I think the unset variant message could use an update.