Skip to content
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

Merged
merged 13 commits into from
Feb 1, 2022
Merged

Schema a d #1211

merged 13 commits into from
Feb 1, 2022

Conversation

blackboxsw
Copy link
Collaborator

@blackboxsw blackboxsw commented Jan 24, 2022

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:

  • cc_apt_configure
  • cc_bootcmd
  • cc_byobu
  • cc_chef (migrated)
  • cc_debug
  • cc_disable_ec2_metadata

Proposed Commit Message

schema: add static JSON schema for some a-c config modules

Migrate from legacy schema or define new schema in 
cloud-init-schema.json, adding extensive schema tests for:
- cc_apt_configure
- cc_bootcmd
- cc_byobu
- cc_ca_certs
- cc_chef
- cc_debug
- cc_disable_ec2_metadata
- cc_disk_setup

- Add schema alias `ca_certs.remove_defaults` for `ca-certs.remove-defauts`
- Add deprecation warnings for use or ca-certs and remove-defaults
- Extend apt_configure schema
   - Define more strict schema below object opaque keys using
     patternProperties
  -  create common $def apt_configure.mirror for reuse in 'primary' 
     and 'security' schema definitions within cc_apt_configure

 Co-Authored-by: James Falcon <james.falcon@canonical.com>

Additional Context

Test Steps

# review generated docs
PYTHONPATH=. python3 -m cloudinit.cmd.main devel schema --docs cc_apt_configure
PYTHONPATH=. python3 -m cloudinit.cmd.main devel schema --docs cc_bootcmd
PYTHONPATH=. python3 -m cloudinit.cmd.main devel schema --docs cc_byobu
PYTHONPATH=. python3 -m cloudinit.cmd.main devel schema --docs cc_chef
PYTHONPATH=. python3 -m cloudinit.cmd.main devel schema --docs cc_ca_certs
PYTHONPATH=. python3 -m cloudinit.cmd.main devel schema --docs cc_debug
PYTHONPATH=. python3 -m cloudinit.cmd.main devel schema --docs cc_disable_ec2_metadata

# Exercise valid/invalid schema
tox -e py3 tests/unittests/config

Checklist:

  • My code follows the process laid out in the documentation
  • I have updated or added any unit tests accordingly
  • I have updated or added any documentation accordingly

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.
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
Copy link
Member

@holmanb holmanb left a 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.

cloudinit/config/cc_apt_configure.py Show resolved Hide resolved
cloudinit/config/cloud-init-schema.json Outdated Show resolved Hide resolved
Copy link
Member

@TheRealFalcon TheRealFalcon left a 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?

cloudinit/config/cc_bootcmd.py Show resolved Hide resolved
"type": ["string", "boolean", "array"],
"default": false,
"oneOf": [
{"type": "string", "enum": ["auto", "remove"]},
Copy link
Collaborator Author

@blackboxsw blackboxsw Jan 31, 2022

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"?

Copy link
Member

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.

Copy link
Collaborator Author

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.
Copy link
Collaborator Author

@blackboxsw blackboxsw left a 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:

  1. 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.
  2. 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?
  3. Should we define our current strict schema to still support the "old schema" for apt_configure?

Copy link
Member

@TheRealFalcon TheRealFalcon left a 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.

if "ca-certs" in cfg:
log.warning(
"DEPRECATION: key 'ca-certs' is now deprecated. Use 'ca_certs' by"
" version 23.1."
Copy link
Member

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.

Copy link
Collaborator Author

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 Show resolved Hide resolved
log.debug(
"Skipping module named %s, no 'ca-certs' key in configuration",
name,
)
return

ca_cert_cfg = cfg["ca-certs"]
else:
Copy link
Member

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.

Copy link
Collaborator Author

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

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."
Copy link
Member

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

Copy link
Collaborator Author

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.

@holmanb
Copy link
Member

holmanb commented Jan 31, 2022

2. `apt_configure`: has a [convert_v1_to_v2_apt_format](https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_apt_configure.py#L889) 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?

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 cloud-init devel schema to warn of deprecated config format usage (which would maybe check some metadata stored in the schema?). In my mind this lands outside the scope of this PR, but since this PR touches on deprecation in a couple different ways I wanted to bring it up to see what others' thoughts are.

Copy link
Member

@holmanb holmanb left a 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

@blackboxsw
Copy link
Collaborator Author

blackboxsw commented Jan 31, 2022

Do we have a well defined user story around handling config deprecation in cloud-init? If we don't, maybe we could enhance cloud-init devel schema to warn of deprecated config format usage (which would maybe check some metadata stored in the schema?). In my mind this lands outside the scope of this PR, but since this PR touches on deprecation in a couple different ways I wanted to bring it up to see what others' thoughts a

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

Copy link
Member

@TheRealFalcon TheRealFalcon left a 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.

@blackboxsw blackboxsw merged commit af7eb1d into canonical:main Feb 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants