Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove CRDs from tigera-operator.yaml #9518

Merged
merged 11 commits into from
Nov 28, 2024
Merged

Remove CRDs from tigera-operator.yaml #9518

merged 11 commits into from
Nov 28, 2024

Conversation

caseydavenport
Copy link
Member

@caseydavenport caseydavenport commented Nov 22, 2024 •
edited
Loading

Description

Trying this out. It removes the CRDs from tigera-operator.yaml to reduce the size of the manifest.

Instead, it configures the operator pod itself to create these CRDs on startup.

The main consequences I can see are:

  • operator-init container in OCP will try to create resources before CRDs exist. May need to adjust the code.
  • users will need to wait for operator pod to be running before applying custom-resources.yaml

But I think this is probably worth trying out.

Related issues/PRs

Fixes #9517

Requires: tigera/operator#3610

Todos

  • Tests
  • Documentation
  • Release note

Release Note

To reduce manifest size, tigera-operator.yaml no longer includes CustomResourceDefinitions. Instead, the tigera-operator pod will deploy these resources on startup.

Reminder for the reviewer

Make sure that this PR has the correct labels and milestone set.

Every PR needs one docs-* label.

  • docs-pr-required: This change requires a change to the documentation that has not been completed yet.
  • docs-completed: This change has all necessary documentation completed.
  • docs-not-required: This change has no user-facing impact and requires no docs.

Every PR needs one release-note-* label.

  • release-note-required: This PR has user-facing changes. Most PRs should have this label.
  • release-note-not-required: This PR has no user-facing changes.

Other optional labels:

  • cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.
  • needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.

@caseydavenport caseydavenport requested a review from a team as a code owner November 22, 2024 15:57
@marvin-tigera marvin-tigera added this to the Calico v3.30.0 milestone Nov 22, 2024
@marvin-tigera marvin-tigera added release-note-required Change has user-facing impact (no matter how small) docs-pr-required Change is not yet documented labels Nov 22, 2024
@caseydavenport caseydavenport mentioned this pull request Nov 22, 2024
Closed
@caseydavenport
Copy link
Member Author

Actually looking at it, I think this doesn't impact OCP since we install CRDs as distinct manifests in that env.

@caseydavenport
Copy link
Member Author

Suspect there is some more operator work required before merging this, but not too much.

@lwr20
Copy link
Member

lwr20 commented Nov 25, 2024 •
edited
Loading

users will need to wait for operator pod to be running before applying custom-resources.yaml

If we continue to provide the CRDs manifest, presumably users can continue to deploy them if they want to (and therefore apply custom-resources.yaml before operator)

Is there mileage in just including the CRDs required for custom-resources in the operator yaml? Or are they all needed?

@caseydavenport
Copy link
Member Author

@lwr20 I think there is mileage in that, although I'd need to think about what work is required on our end to make that happen. Not obvious how we get our generation code to do that nicely.

There's a part of me that says "Let's just roll this out and see how it fares" - it's still possible that even including our operator CRDs can exceed maximum sizes in some cases (if not now, then eventually)

@coutinhop
Copy link
Contributor

LGTM, one question about manifests/ocp/policy.networking.k8s.io_adminnetworkpolicies.yaml: that's not a calico CRD per se, but it might be nice to have the operator take care of it and to remove the yaml from here as well, what do you think?

@coutinhop coutinhop merged commit 6617031 into projectcalico:master Nov 28, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@coutinhop coutinhop coutinhop approved these changes

Assignees
No one assigned
Labels
docs-pr-required Change is not yet documented release-note-required Change has user-facing impact (no matter how small)
Projects
None yet
Milestone
Calico v3.30.0
Development

Successfully merging this pull request may close these issues.

Classic Calico-Installation (kubectl apply) should have a smaller footprint
4 participants
@caseydavenport @lwr20 @coutinhop @marvin-tigera