✨ Validate CloudConfig using schema #305
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
testing-needed-e2e-fast
size/XXL
akutz
force-pushed
the
feature/validate-marshaled-cloud-init-userdata-against-schema
branch
2 times, most recently
from
4042057 to
9b571fc
Compare
akutz
force-pushed
the
feature/validate-marshaled-cloud-init-userdata-against-schema
branch
2 times, most recently
from
0a934e7 to
033bd91
Compare
bryanv
approved these changes
Dec 15, 2023
akutz
force-pushed
the
feature/validate-marshaled-cloud-init-userdata-against-schema
branch
from
033bd91 to
639f834
Compare
This patch ensures the CloudConfig YAML produced by the inline CloudInit spec is validated against the official CloudConfig schema from Cloud-Init. This patch also relocates the `cloudinit` utility package from `./pkg/vmprovider/providers/vsphere2/cloudinit` to `./pkg/util/cloudinit`. Since we do no anticipate future API revisions as a _huge_ departure from what has been established in v1alpha2, it is safe to use those types in utility code as they can be find/replaced with later schema versions, ex. `v1alpha3`, when that time comes. Other than the reference to a `github.com/vmware-tanzu/vm-operator/api/v1alpha2/cloudinit.CloudConfig`, the code in `./pkg/util/cloudinit` is completely unrelated to the vSphere provider, hence its relocation under the utility package.
akutz
force-pushed
the
feature/validate-marshaled-cloud-init-userdata-against-schema
branch
from
639f834 to
5709ca5
Compare
|
Merging as there were successful integration test runs already, and the last two have failed due to an unrelated image flake and the second a race condition. |
Minimum allowed line rate is |
akutz
deleted the
feature/validate-marshaled-cloud-init-userdata-against-schema
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What does this PR do, and why is it needed?
This patch ensures the CloudConfig YAML produced by the inline CloudInit spec is validated against the official CloudConfig schema from Cloud-Init.
This patch also relocates the
cloudinitutility package from./pkg/vmprovider/providers/vsphere2/cloudinitto./pkg/util/cloudinit. Since we do no anticipate future API revisions as a huge departure from what has been established in v1alpha2, it is safe to use those types in utility code as they can be find/replaced with later schema versions, ex.v1alpha3, when that time comes. Other than the reference to agithub.com/vmware-tanzu/vm-operator/api/v1alpha2/cloudinit.CloudConfig, the code in./pkg/util/cloudinitis completely unrelated to the vSphere provider, hence its relocation under the utility package.Which issue(s) is/are addressed by this PR? (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes
NONEAre there any special notes for your reviewer:
I considered using the validation logic to also verify the raw cloud config, but I elected to not do this for the following reasons:
In other words, the raw cloud config is not just a means to send in data that our version of the schema may consider to be invalid, but it's a way to ensure users have a way to bypass validation entirely if that is what they want to do.
Please add a release note if necessary: