You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Can the Calico or Tigera operator install Calico CustomResourceDefinitions (CRDs) directly? Similar to what Cilium does.
I noticed all the Calico and Tigera docs still talk about using kubectl to install either the Tigera operator or Calico directly.
When you look at the YAML, there are a ton of CRDs I'm expected to manage. The trouble is, we manage these declaratively. As a Kubernetes distro maintainer, it's becoming onerous to have to port Calico's CRDs every release. I'd rather just delegate this completely to the operator to install and manage. After all, it's Calico's own CRDs, it ought to be able to manage them.
Current Behavior
We're expected to apply CRDs either through kubectl or Helm (frowned upon) right now. Or otherwise pay attention to changes in the CRDs.
Possible Solution
cilium-operator creates or updates it's own CRDs when it starts. And it has RBAC to only allow managing those CRDs so its fine by any security team. As a result, nobody has to worry about the minor differences they make to their CRDs between releases, it's abstracted away.
Steps to Reproduce (for bugs)
Context
Your Environment
Operating System and version:
Link to your project (optional): Typhoon
The text was updated successfully, but these errors were encountered:
This seems like a reasonable feature to add.
The operator does have the ability to update them if configured with a command line flag but does not have the ability to initially create them.
If someone wants to take this on, the expectation would be that in the main the operator would create them if they do not exist before starting up the controllers. If you have more questions please ask.
Expected Behavior
Can the Calico or Tigera operator install Calico CustomResourceDefinitions (CRDs) directly? Similar to what Cilium does.
I noticed all the Calico and Tigera docs still talk about using kubectl to install either the Tigera operator or Calico directly.
When you look at the YAML, there are a ton of CRDs I'm expected to manage. The trouble is, we manage these declaratively. As a Kubernetes distro maintainer, it's becoming onerous to have to port Calico's CRDs every release. I'd rather just delegate this completely to the operator to install and manage. After all, it's Calico's own CRDs, it ought to be able to manage them.
Current Behavior
We're expected to apply CRDs either through kubectl or Helm (frowned upon) right now. Or otherwise pay attention to changes in the CRDs.
Possible Solution
cilium-operator creates or updates it's own CRDs when it starts. And it has RBAC to only allow managing those CRDs so its fine by any security team. As a result, nobody has to worry about the minor differences they make to their CRDs between releases, it's abstracted away.
Steps to Reproduce (for bugs)
Context
Your Environment
The text was updated successfully, but these errors were encountered: