[Feedback needed] Use OpenAPI v3 endopint for manifest schema discovery

[yhrn]

Rollback Plan

If a change needs to be reverted, we will publish an updated version of the library.

Changes to Security Controls

I'm not sure if this is relevant for this section, but this change would mean that the Terraform user would no longer need CRD related permissions (unless the managed resources includes actual CRDs of course, i.e. addressing #1665).

Description

This PR changes the behavior of kubernetes_manifest schema discovery to prefer the openapi/v3 endpoint over listing CRDs and falling back to openapi/v3. More Info in #2769. I will also add information here once it is decide how this new behavior should be controlled.

Acceptance tests

• Have you added an acceptance test for the functionality being added?
• Have you run the acceptance tests on this branch?

I have not added any acceptance tests because this changes are tested by all the existing manifest acceptance tests.

Output from acceptance testing:

All manifest acceptance tests pass in my local setup against a kind cluster, with the only exception that the CertManager tests fails during cleanup. However, I get excatly the same problem when running the tests on main.

Release Note

Release note for CHANGELOG:

...I will update this once the PR is out of draft and the open questions have been resolved...

References

• Resolves kubernetes_manifest to Prefer OpenAPI v3 schema #2769
• Resolves CRD api access error on kubernetes_manifest prevents a non-CRD resource to be created. #1507
• Resolves kubernetes_manifest listing all CRDs each time #1651
• Resolves kubernetes_manifest resource should NOT make any CRD call  #1665
• Addresses feature: ability to manage CRDs in KCP using terraform kcp-dev/kcp#3333
• Kubernetes blog post about OpenAPI v3 support GA

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

[hashicorp-cla-app]

All committers have signed the CLA.

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

---

Mattias Öhrn seems not to be a GitHub user.
You need a GitHub account to be able to sign the CLA.
If you have already a GitHub account, please add the email address used for this commit to your account.

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[yhrn]

The big open question is how the new behavior would be controlled. Right now it just tries to read from /openapi/v3 and if that fails for any reason it falls back to the old behavior. This is definitely not what we want, but I don't want to spend time implementing something more robust before I know what that is.

Some options:

1. Similar to now but ensure that the only error that causes fallback to the old behavior is if ´/openapi/v3´ doesn't exist (404, no intermittent errors)
2. Completely remove the old behavior and say that from now on the provider only works with ´/openapi/v3´. This means that older (and unsupported since 18 months or more) k8s versions would no longer be supported by this provider. This would also make it possible to remove a fair bit on code and complexity from the provider.
3. Make the behavior configurable through provider configuration.