backend/kubernetes: Remove legacy helper/schema dependency #34988
+260
−222
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As with most of our remote state backends, this one was depending on just a tiny slice of the (enormous and now-poorly-understood) legacy SDK.
In an effort to eliminate the legacy SDK snapshot from this codebase, this replaces it with functionality from our new "backendbase" package, which aims to provide just a narrow set of utilities to minimize the churn caused by removing the legacy SDK and thus reduce the risk of this change.
This is currently using the "SDK-like" utilities, which emulate some of the questionable-but-convenient assumptions the legacy SDK makes, such as the idea that empty string and null are equivalent. Hopefully in future we can wean this backend even further off of these older assumptions, but the priority for now is to eliminate the legacy SDK without significantly disturbing the shape of the existing working code.
In the long run we're still planning to move all of the state storage backends out to provider plugins, but the legacy SDK is quite a liability because few people know how to maintain it while hopefully this interim
backendbase
package is easier to maintain in the meantime (if needed) due to its relative simplicity.I don't have any test environment for this backend, so I've only tested this through its unit tests. I'd appreciate if a backend maintainer could, along with reviewing this code, also run the acceptance test suite in case there are regressions that the unit tests aren't able to catch. Thanks!