Do less Kubernetes API requests

[g7r]

Description

The first reason why provider does so many requests is because its caches aren't goroutine-safe. For example, Terraform invokes provider concurrently and every individual goroutine starts its own getOAPIv2Foundry() invocation. Every getOAPIv2Foundry() starts its own Kubernetes API request and these requests consume Kubernetes client Burst leading eventually to a stall.

The second reason is that CRDs should also be cached because production Kubernetes clusters may have lots and lots of CRDs and getting them all is not cheap. Furthermore, getting them over and over consumes Kubernetes client Burst leading to a major stall.

Release Note

Release note for CHANGELOG:

Do less Kubernetes API invocations
Make `RawProviderServer` caches goroutine-safe

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.

[g7r]

Hello @alexsomesan, @jrhouston, and @arybolovlev,

Hope you're having a good week.

I submitted this PR about a month ago and just wanted to gently follow up to make sure the notification came through and it landed on your radar.

This PR has two main benefits: it addresses a significant performance issue (reducing terraform plan time from ~3 minutes back down to ~15 seconds) and also helps make the provider's behavior more correct in this context.

I'd be grateful if you could take a look when you have a moment.

Thank you for your consideration and all your work on this provider!

[alexsomesan]

Hello @alexsomesan, @jrhouston, and @arybolovlev,

Hope you're having a good week.

I submitted this PR about a month ago and just wanted to gently follow up to make sure the notification came through and it landed on your radar.

This PR has two main benefits: it addresses a significant performance issue (reducing terraform plan time from ~3 minutes back down to ~15 seconds) and also helps make the provider's behavior more correct in this context.

I'd be grateful if you could take a look when you have a moment.

Thank you for your consideration and all your work on this provider!

Hello @g7r
Thanks for taking the time to look into these performance issues.

Our whole team is away this week, taking part in a company event. I will have a look at your PR first thing next week, when I'm back to a regular schedule.