Closed aareet closed 3 years ago
I just wanted to leave a quick test here for anyone who might be hitting this issue. To confirm if it's a server-side apply issue, it can be helpful to test your manifest in yaml using kubectl, like this:
$ kubectl apply -f redis.yaml -n test --server-side
verticalpodautoscaler.autoscaling.k8s.io/redis-vpa serverside-applied
deployment.apps/redis-master serverside-applied
I thought I was hitting a server-side apply issue, but since this worked it indicates that my yaml works fine on the server-side.
I'd like the ability to be able to plan with a read only RBAC role. At the moment when trying that using server-side planning, against an existing CRD that I have only have get
access for, I receive:
Error: rpc error: code = Unknown desc = update dry-run for '/<CRD-NAME>' failed: customresourcedefinitions.apiextensions.k8s.io "<CRD-NAME>" is forbidden: User "<USER-NAME>" cannot patch resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope
(adding the patch
verb to the role does resolve this but I'd like to provide read-only access for this use case)
Is this something that local planning will solve - or should I create a new issue for this use case?
Possibly of note - I did also try setting server_side_planning = false
in the provider config after seeing that option in another issue, which I then received:
Error: rpc error: code = Unknown desc = failed to get resource type from OpenAPI (ID io.k8s.apiextensions-apiserver.pkg.apis.apiextensions.v1beta1.CustomResourceDefinition): unknown type:
(I'm only half aware of what i'm doing here - am figuring it out as a go - so apologies if this is not the same thing as this issue!)
Yes, local planning should enable you to plan (but not apply) the read-only configuration you described. It no longe tries to make dry-run API calls during plan which is what I suspect triggers the error you're seeing. Bear in mind, with local planning, the provider needs to be able to retrieve the OpenAPI spec document from the API server. Not sure if that is subject to any access control. In order to use local planning you have to wait for PR #41 to merge. The current state of it in master is not quite functional.
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!
Description
Currently, we use the Server Side Planning feature as default in our provider configuration. This option comes with limitations on the complexity of resources that can be managed with this provider. Implement the option of local planning to allow greater complexity of resources and richer configuration validation.
Community Note