-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add an option to pass requests through the filtered cache #1729
Comments
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
1 similar comment
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
After discussion on #1715 , more specifically from
#1715 (comment)
It was thought that the addition of an option that allowed client requests to get resources that were not cached would solve some use cases.
If an operator uses the filtered cache with matchers for all the resources it owns and manages it becomes likely that it will not be able to access any resources managed by anything else, unless it has set some common labels with those set by the operator. For example, if an operator is created to install application with a filtered cache and it utilises cert manager, it becomes impossible for that operator to access the secrets created by cert manager (the secrets can be mounted, but the operator itself cannot get the secrets if it wanted to move them around or something).
The proposed solution would be to add an option that will allow the client to get these resources even if they aren't cached, this would mean that if the resource isn't found in the cache it is attempted to be found in the cluster. This opens up a potential problem that it is not possible to determine between something that is not cached and something that does not exist at all, leading to potentially excessive api calls. However I think this is mitigated because if the resource is cached the cost is the same, and if it exists but isn't cached it solves the above use case which is the desired behaviour, and it is optional it can be turned off. Therefore the only time it causes a problem is if the operator is spamming out requests for a resource that doesn't exist in the cluster with this option turned on
The text was updated successfully, but these errors were encountered: