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.

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

Option to manage CRDs separately from the main cluster object #124

Open
pgier opened this issue Aug 4, 2023 · 2 comments
Open

Option to manage CRDs separately from the main cluster object #124

pgier opened this issue Aug 4, 2023 · 2 comments

Comments

@pgier
Copy link
Collaborator

pgier commented Aug 4, 2023

I'm running into some problems due to the large size of the cluster CRD. I sometimes get memory errors in K9s/kubectl, and it can be a bit difficult to find the config I'm looking for. I would like to have a mode where the cluster CRD just has a flag to tell it to manage a proxy CRD. That way I can work directly with the proxy config without affecting config of the other components.

@nicoloboschi
Copy link
Contributor

nicoloboschi commented Aug 14, 2023

This is not doable since the internal CRDs are not meant for it.

What are the errors you're seeing?
We could look at reducing the CRD size but it's really hard now.

One thing I've noticed with kubectl is that using --server-side helps

@pgier
Copy link
Collaborator Author

pgier commented Aug 14, 2023

I get errors when using kubectl edit to edit the PulsarCluster resource directly. I realize this is probably a big request, so I guess this one can be pushed back, it's more just a convenience.

E363: Pattern uses more memory than 'maxmempattern'

As far as implementation, I was thinking you could just set a flag in the PulsarCluster to say managedIndependently or something for the proxy for example, and then the operator just picks up config directly from the Proxy custom resource.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants