-
Notifications
You must be signed in to change notification settings - Fork 908
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Schema a d #1211
Schema a d #1211
Conversation
Move definition into cloud-init-schema.json
Migrate legacy apt_configure schema to new cloud-init-schea.json Add common $defs for 'primary' and 'security' keys. Use patterProperties for opaque "apt.sources" key. Make schema more strict by adding minProperties:1 and additionalProperties: False where applicable for objects. this should avoid some typos and accidental ommisions.
Migrate legacy chef schema to new cloud-init-schea.json. Add more strict schema definition disallowing additionalProperties. Add extensive unittests for invalid schemas.
93443c9
to
0e0f207
Compare
migrate to statis cloud-init-schema.json and add unittests
Migrate to static cloud-init-schema.json and add unittests
Migrate to static cloud-init-schema.json and add unittests Needs more unittests for failure cases
552e48b
to
c1f38f8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I've seen looks good so far; I like the general approach. I still have more to review, but there are a couple of minor nits I'll share right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! One inline nit and a question (in addition to Brett's comments).
You mentioned you thought there might be an issue with disk setup, but I don't remember the details. Can you explain the issue?
"type": ["string", "boolean", "array"], | ||
"default": false, | ||
"oneOf": [ | ||
{"type": "string", "enum": ["auto", "remove"]}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheRealFalcon here is the error or inconsistency I was referring to in both disk-setup:
documentation and schema definition I think. I can't find in our python code where layout of "auto" is honored or used so I think it might not be correct (maybe a thinko for the original module writer due to "partition" key supporting "auto"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@blackboxsw , yes, good catch. auto
isn't valid here. I suspect it may have been sometime in the past because there was also an example that had auto
(that I removed), but apparently I missed taking it out of the schema. We should be able to safely remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 will remove it now.
Add aliases in cloud-init schema and cc_ca_certs module to support both deprecated ca-certs.remove-defaults and ca_certs.remove_defaults. Update docs to show ca_certs instead of ca_certs. Also drop unused apt_configure.py mirror_property variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@holmanb @TheRealFalcon I've just pushed additional changes to add a warning log about deprecation of "ca-certs" key in favor of "ca_certs" to make sure we don't suprise folks by rejecting that in the new strict schema.
Also, I've aliased a "ca-certs" key to "ca_certs" in the cloud-init schema so schema validation doesn't raise an error or warning on the deprecated ca-certs key.
Two more questions I have:
disk-setup:
layout seems to include an "auto" value in both docs and schema, but I don't see the matching cc_disk_setup logic that honors this value. So, I'm not certain we need it.apt_configure
: has a convert_v1_to_v2_apt_format which supports a different schema forapt_configure
than we have captured in our current strict schema. Shall we emit deprecation warnings for old uses ofapt
in this release?- Should we define our current strict schema to still support the "old schema" for apt_configure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
apt_configure: has a convert_v1_to_v2_apt_format which supports a different schema for apt_configure than we have captured in our current strict schema. Shall we emit deprecation warnings for old uses of apt in this release?
Yes, I think that makes sense, especially since we don't even document v1 anymore.
Should we define our current strict schema to still support the "old schema" for apt_configure?
I don't think so. It's still just a warning, right? If they got the warning before, they'll continue to get the warning now.
cloudinit/config/cc_ca_certs.py
Outdated
if "ca-certs" in cfg: | ||
log.warning( | ||
"DEPRECATION: key 'ca-certs' is now deprecated. Use 'ca_certs' by" | ||
" version 23.1." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this date is reasonable unless it's only for upstream. In order to maintain backwards compatibility, we either will have to patch downstream or extend this date to April 2025.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, setting this drop version or date is arbitrary. Ideally, I'd like to drop this everywhere, but I don't know what line in the sand we should set for this. I don't love the idea of patching out behavior on older releases..... but in order to retain original behavior, maybe that is a debt we need to pay to move upstream forward to a unified/strict schema. We can sort how to handle deprecation timing separately in a different PR for these types of conditions (ca-certs -> ca_certs deprecation. and apt_configure v1 vs v2 deprecation).
cloudinit/config/cc_ca_certs.py
Outdated
log.debug( | ||
"Skipping module named %s, no 'ca-certs' key in configuration", | ||
name, | ||
) | ||
return | ||
|
||
ca_cert_cfg = cfg["ca-certs"] | ||
else: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's that small possibility they provide both ca-certs
and ca_certs
. In that case I think we should log a warning and use ca_certs
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 added warning and unit test
cloudinit/config/cc_ca_certs.py
Outdated
if "remove-defaults" in ca_cert_cfg: | ||
log.warning( | ||
"DEPRECATION: key 'ca-certs.remove-defaults' is now deprecated." | ||
" Use 'ca_certs.remove_defaults' by version 23.1." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing about the date here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1. as it is currently. I've just added the DEPRECATION warning and dropped the version suggestion from this PR. We can sort how/when to deprecate a number of schema related values as a separate PR since there will be multiple cases by the time we get through all cc_* modules.
I'm generally in favor of deprecating old formats so we can lay this kind of conversion code to rest. That said, user experience around these kinds of "forced changes" is probably important. Do we have a well defined user story around handling config deprecation in cloud-init? If we don't, maybe we could enhance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spelling nits:
spellintian cloudinit/config/cloud-init-schema.json
cloudinit/config/cloud-init-schema.json: dependancies -> dependencies
cloudinit/config/cloud-init-schema.json: partion -> partition
Unfortunately, we don't. I agree with a deprecation warning generally from schema validate to better raise awareness of that expected failure in the future. I've seen a couple of public JSON schemas that add a "deprecated" bool to a property in the schema definition but we also risk mixing metadata w/ true/strict schema definitions. Maybe it's still worth injecting that data into our schema to better raise awareness of the eventual drop of said properties. We could also leverage such an attribute for our generated docs to render that deprecation warning as well in readthedocs content. +1 on outside the scope of this PR, but let's talk on this and come up with a consensus on best approach to handle this case and put a PR during our schema work to address it. Created this JIRA issue to track better deprecated cloud-config schema in docs/tooling/logs https://warthogs.atlassian.net/browse/SC-774 |
0d9671b
to
7207765
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! Thanks for getting this the rest of the way to the finish line.
Based on James' schema-a-d PR 1155l migrate legacy schema definitions to static cloud-init-schema.json.
modules migrated, extended and schema unittests added:
Proposed Commit Message
Additional Context
Test Steps
Checklist: