-
Notifications
You must be signed in to change notification settings - Fork 911
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: add json defs for modules scripts-timezone (SC-801) #1365
schema: add json defs for modules scripts-timezone (SC-801) #1365
Conversation
|
||
frequency = PER_INSTANCE | ||
MODULE_DESCRIPTION = """\ | ||
Any scripts in the ``scripts/vendor`` directory in the datasource will be run | ||
when a new instance is first booted. Scripts will be run in alphabetical order. |
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 think we should update docs to somehow mention the run order of script config modules is [vendor, per-once, per-boot, per-instance, user].
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.
If one cares about ordering, they would need to check /etc/cloud/cloud.cfg, and I think we need to find a way to document that separately. I don't disagree that it should be documented, but I'm not sure the module documentation is the best place for 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.
almost done w/ cc_set_passwords but wanted to add comments before I EOW. cc_snap looks insteresting as I wonder if we want to use patternProperties schema to handle reprensenting the underlying lists below the opaque-keys. will get back to this monday.
"perserve_hostname: true", | ||
dedent( | ||
"""\ | ||
hostname: myhost |
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.
We could explain in a comment expected behavior is for /etc/hostname and or /etc/hosts. But, maybe the description above handles that well enough.
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.
Isn't a lot of it technically distro-dependent? Also the interaction between this module and update_hostname is still confusing to me and I think it could probably be simplified down into one module...but not 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.
It is distro-dependent, so that extra context isn't helpful in all cases. We do have a number of questions about this behavior in bugs and IRC that keep surfacing. What we have in the MODULE_DESCRIPTION is probably good enough. Agreed that restructuring modules is not on our agenda for this effort and we can improve the documentation with tutorials you've started and or ammendment to use-cases.
Pushed 2 commits (one just for vendor data) addressing comments |
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 need to come back to cc_ssh but wanted to give you a second round of feedback first.
"perserve_hostname: true", | ||
dedent( | ||
"""\ | ||
hostname: myhost |
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.
It is distro-dependent, so that extra context isn't helpful in all cases. We do have a number of questions about this behavior in bugs and IRC that keep surfacing. What we have in the MODULE_DESCRIPTION is probably good enough. Agreed that restructuring modules is not on our agenda for this effort and we can improve the documentation with tutorials you've started and or ammendment to use-cases.
}, | ||
"squashfuse_in_container": { | ||
"type": "boolean", | ||
"description": "**Development only**: The ``squashfuse_in_container`` boolean can be set true to install squashfuse package when in a container to enable snap installs. Default: ``false``." |
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.
Let's add DEPRECATION to this key too. we no longer officially need this on Bionic++ because to install snaps because https://bugs.launchpad.net/snappy/+bug/1628289 has been fix released a while back (and we no longer support Xenial). I think we can actually drop the maybe_install_squashfuse function from cc_snap Let's take it as a separate work item though from this PR though.
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 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.
Duplicate of https://warthogs.atlassian.net/browse/SC-903
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.
Ahhh, thanks. Deleted
}, | ||
"blacklist": { | ||
"type": "array", | ||
"description": "The SSH key types to blacklist when publishing. Default: ``[dsa]``", |
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.
"description": "The SSH key types to blacklist when publishing. Default: ``[dsa]``", | |
"description": "The SSH key types to ignore when publishing. Default: ``[dsa]``", |
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.
Once we add the ability to hide schema properties from the docs, I'd like to deprecate this and replace it with 'denylist'
cloudinit/stages.py
Outdated
@@ -757,6 +757,12 @@ def _consume_vendordata(self, vendor_source, frequency=PER_INSTANCE): | |||
LOG.debug("%s consumption is disabled.", vendor_source) | |||
return | |||
|
|||
if isinstance(enabled, str): | |||
LOG.debug( | |||
"Use of string for 'vendor_data:enabled' field is " |
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.
Let's add the value here for debug/triage purposes.
"Use of string for 'vendor_data:enabled' field is " | |
f"Use of string '{enabled}' for 'vendor_data:enabled' field is " |
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.
Minor schema fix with vendor_data.prefix otherwise LGTM!
diff --git a/cloudinit/config/cloud-init-schema.json b/cloudinit/config/cloud-init-schema.json
index 43e90e1a4..96dec0a7c 100644
--- a/cloudinit/config/cloud-init-schema.json
+++ b/cloudinit/config/cloud-init-schema.json
@@ -1356,7 +1356,9 @@
"description": "Whether vendor data is enabled or not. Use of string for this value is DEPRECATED. Default: ``true``"
},
"prefix": {
- "type": ["boolean", "string"],
+ "type": ["array", "string"],
+ "items": {"type": ["string", "integer"]},
+ "minItems": 1,
"description": "The command to run before any vendor scripts. Its primary use case is for profiling a script, not to prevent its run"
}
}
diff --git a/tests/unittests/config/test_cc_scripts_vendor.py b/tests/unittests/config/test_cc_scripts_vendor.py
index a8cbfb4f4..69a5fe801 100644
--- a/tests/unittests/config/test_cc_scripts_vendor.py
+++ b/tests/unittests/config/test_cc_scripts_vendor.py
@@ -1,3 +1,5 @@
+import re
+
import pytest
from cloudinit.config.schema import (
@@ -14,6 +16,10 @@ class TestScriptsVendorSchema:
(
({"vendor_data": {"enabled": True}}, None),
({"vendor_data": {"enabled": "yes"}}, None),
+ (
+ {"vendor_data": {"prefix": []}},
+ re.escape("vendor_data.prefix: [] is too short"),
+ ),
),
)
@skipUnlessJsonSchema()
"description": "Whether vendor data is enabled or not. Use of string for this value is DEPRECATED. Default: ``true``" | ||
}, | ||
"prefix": { | ||
"type": ["boolean", "string"], |
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 think we added wrong "types" in the latest commit for prefix it should be a
"type": ["boolean", "string"], | |
"type": ["array", "string"], | |
"items": {"type": ["string", "integer"]}, | |
"minItems": 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.
@TheRealFalcon CI is failing on this invalid schema definition I believe. Otherwise I think we are good to go.
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.
Gah, sorry. I made the change but never pushed it.
"type": "object", | ||
"description": "A dictionary entries for the public and private host keys of each desired key type. Entries in the ``ssh_keys`` config dict should have keys in the format ``<key type>_private``, ``<key type>_public``, and, optionally, ``<key type>_certificate``, e.g. ``rsa_private: <key>``, ``rsa_public: <key>``, and ``rsa_certificate: <key>``. Not all key types have to be specified, ones left unspecified will not be used. If this config option is used, then separate keys will not be automatically generated. In order to specify multiline private host keys and certificates, use yaml multiline syntax.", | ||
"patternProperties": { | ||
"^(dsa|ecdsa|ecdsa-sk|ed25519|ed25519-sk|rsa)_(public|private|certificate)$": { |
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.
This schema looks ok, but the corresponding code in [cc_ssh.py will silently skip any key type that is not in GENERATE_KEY_NAMES
I think we need to properly handle these other keys and integration testing of them to make sure all is well. Since it's ssh-related I'd like that work to be a separate PR to make sure we get good eyes on it separate from schema coverage
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'll make a ticket
Additionally change module documentation to not show the property header if no property definition exists. Migrate legacy or define new schemas for the following: - cc_scripts_per_boot - cc_scripts_per_instance - cc_scripts_per_once - cc_scripts_user - cc_scripts_vendor - cc_seed_random - cc_set_hostname - cc_set_passwords - cc_snap - cc_spacewalk - cc_ssh_authkey_fingerprints - cc_ssh_import_id - cc_ssh - cc_timezone
0731b90
to
bd486c9
Compare
Fixed the CI issues. Note that this includes a small removal to the vendordata schema. On default LXD launch I'm getting
so we don't want a minItems defined on that. |
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.
Bring it home!
@TheRealFalcon I am seeing something weird after this change. My
And my
Now if I do
And |
The changes to the hostname module appear docs related. Did you bisect to this commit specifically?
This is treated as distro-dependant if @sshedi Please file a bug report with logs if you still believe this to be an issue. |
Thanks for the response @holmanb. I changed Sure, I will file a bug report with necessary data. |
@sshedi Excellent, thank you. FWIW, I do see |
I have created bug with necessary info https://bugs.launchpad.net/cloud-init/+bug/1983811 Please let me know if you need more info. |
Proposed Commit Message