Refactor for terraform-plugin-go SDK and introduce OpenAPI planner

[alexsomesan]

Description

This change reflects a major refactoring of the provider, primarily to transition to using the new Terraform low-level SDK

In addition to that, the following important changes are included in this PR:

Planning using type information from OpenAPI

The provider no longer supports server_side_planning as an option.

Instead, we introduce so called local-planing as the single method of planning. This means the provider now queries the cluster for the OpenAPI spec document and uses the OpenAPI type information for expanding the resource during plan. This has the fundamental advantage that it allows Terraform to understand and record the entire set of attributes of a resource after the first plan, even if not all actually have values configured by the user.

This is crucial for ensuring a reliable resource life-cycle as Terraform does not accept modifications to a resources type structure (adding or removing attributes) after it was first recorded in the state file. Note that this does not refer to attribute values which can be freely set and changed, but rather to the type structure (available set of attributes in a resource).

Previously, the provider implemented two alternatives for producing a plan.

By selected by setting server_side_planning = true, the provider would make a dry-run "Patch" call to the cluster during the plan phase and use the response to populate the plan. This ensured that any "computed" values from the API would be included in the plan and the plan would not produce cyclic diffs. However, this method could not guarantee that the plan structure included all possible attributes of the resource and could potentially lead to apply failures when additional attributes would be added later on.

By selected by setting server_side_planning = false the provider would simply just use the configuration supplied by the user in manifest as the plan and added no other attribute information to it. This had roughly the same disadvantages as the first method, most importantly not capturing the entire structure of the resource type during plan and leading to the same class of issues later on.

Note:
The acceptance tests are using deprecated packages and need to be re-written for the test helpers in the new SDK
These changes have been however extensively tested with real-world manifests from well known Kubernetes applications, among which: Flux v2, ArgoCD, Jetstack CertManager, Thanos, Prometheus Operator, Terraform Cloud Operator, Vault and others.

Some reference modules based on this provider release are available in the Terraform Registry.

Release Note

Release note for CHANGELOG:

Notable changes:
* Refactored to use "github.com/hashicorp/terraform-plugin-go" as a foundation
* Planning now uses types from the cluster's OpenAPI spec to describe each resource
* Simple validation of top-level resource structure & requirement for a namespace value

References

Fixes #3
Fixes #21
Fixes #33
Fixes #34
Fixes #35
Fixes #43
Fixes #48
Fixes #57
Fixes #59
Fixes #69
Fixes #72
Fixes #76
Fixes #88
Fixes #110
Fixes #135
Fixes #143
Fixes #144
Fixes #149

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[aareet]

🚢

[ghost]

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 👉 [email protected]. Thanks!