hashicorp / terraform-provider-kubernetes-alpha

A Terraform provider for Kubernetes that uses dynamic resource types and server-side apply. Supports all Kubernetes resources.
https://registry.terraform.io/providers/hashicorp/kubernetes-alpha/latest
Mozilla Public License 2.0
490 stars 63 forks source link

Enable the use of local planning #34

Closed aareet closed 3 years ago

aareet commented 4 years ago

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

dak1n1 commented 4 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.

tdmalone commented 4 years ago

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!)

alexsomesan commented 4 years ago

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.

ghost commented 3 years ago

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!