#6592 (comment)
CLA signing somehow not working, where can I get help for it ?

@holmanb it should work now, after CLA signing.

Skip datasource loading when --config-file is provided since we're only validating the file's YAML syntax and schema, not system instance data.

@blackboxsw do you know if this command is supposed to be able to validate jinja-based configs? If not, I'm unsure why loading these files would be needed.

Hello! Thank you for this proposed change to cloud-init. This pull request is now marked as stale as it has not seen any activity in 14 days. If no activity occurs within the next 7 days, this pull request will automatically close.

If you are waiting for code review and you are seeing this message, apologies! Please reply, tagging blackboxsw, and he will ensure that someone takes a look soon.

(If the pull request is closed and you would like to continue working on it, please do tag blackboxsw to reopen it.)

@blackboxsw — this PR has gone stale waiting for review. Could you (or someone on the team) take a look when you get a chance?

@holmanb — to address your question: the datasource loading (fetch_existing_datasource="trust") is needed for the --system path, where cloud-init validates the config that actually ran
on a live instance — it needs the datasource to locate instance-data for jinja rendering and to find the processed config files.

With --config-file, the use case is different: users are authoring or debugging their cloud-config YAML locally before deploying (as documented in
https://cloudinit.readthedocs.io/en/latest/howto/debug_user_data.html). In this case, the file path is already provided, jinja variables can be supplied separately via --instance-data,
and loading the system datasource is unnecessary. The current code still attempts it though, causing a confusing EACCES warning when a non-root user runs something as simple as
cloud-init schema -c my-config.yml.

Happy to make any adjustments if needed.