3 ms·

> I would need to open a PR to the repo and wait weeks, sometimes months, for a new release. Just curious, is this a limitation of the Operators framework, or

> I would need to open a PR to the repo and wait weeks, sometimes months, for a new release. Just curious, is this a limitation of the Operators framework, or that of your system's implementation? My knee-jerk reaction is that any implementation should absolutely not require opening ticket. After all, Amazon's API mandate happened 20 years ago, and Netflix followed suit to achieve phenomenal productivity for their engineers. I have a hard time imagining why any engineer would think that gatekeeping configuration with PR is a good idea(a UI with proper automation and approval process that hides generated PR for specific use cases is a different matter)

IceWreck 4y ago
Not a kubernetes expert, but my understanding is that that operators are regular programs that run in a kubernetes container and interact with the kubernetes API to launch/manage other containers and custom kubernetes resources. An operator (or its custom resource) can be configured by Kubernetes YAML/API and its upto the creator of the operator to specify the kind of configuration. If the operator creator did not specify options to set cpu/memory limits on the pods managed by the operator, then you can't do anything. You have to add that feature into the operator and then make a pull request and wait for it to be upstreamed. Or fork it instead. Same thing for helm charts (except forking and patching them is easier than forking an operator).