Cloud config modules are not skipped based on distro support

[ubuntu-server-builder]

This bug was originally filed in Launchpad as LP: #1715738

Launchpad details

affected_projects = []
assignee = chad.smith
assignee_name = Chad Smith
date_closed = 2017-09-23T02:35:56.237638+00:00
date_created = 2017-09-07T20:27:22.377586+00:00
date_fix_committed = 2017-09-14T16:34:21.180601+00:00
date_fix_released = 2017-09-23T02:35:56.237638+00:00
id = 1715738
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1715738
milestone = 0.7.10
owner = chad.smith
owner_name = Chad Smith
private = False
status = fix_released
submitter = chad.smith
submitter_name = Chad Smith
tags = []
duplicates = []

Launchpad user Chad Smith(chad.smith) wrote on 2017-09-07T20:27:22.377586+00:00

cloudinit.stages emits logs messages like the following when the cloudconfig module's distro attribute doesn't match the running disribution

When a cloudinit.config.cc*py module distros attribute doesn't match the discovered Distribution.name, cloudinit.stages emits a log message about skipping the module in the following form:

2017-09-07 06:03:25,838 - stages.py[INFO]: Skipping modules ['runcmd'] because they are not verified on distro 'ubuntu'. To run anyway, add them to 'unverified_modules' in config.

But, it doesn't actually skip running the module, we can see in the logging that follows:
Running module runcmd (<module 'cloudinit.config.cc_runcmd' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_runcmd.py'>) with frequency once-per-instance.

cloudinit.stages should honor a skipped module and avoid running its handler.

[ubuntu-server-builder]

Launchpad user Chad Smith(chad.smith) wrote on 2017-09-07T20:31:37.779387+00:00

Might also look into unverified_modules behavior, it looks like it is ineffective as well. Just a log message and no further change in behavior made by run_section.

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2017-09-23T02:35:58.967151+00:00

This bug is believed to be fixed in cloud-init in 17.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.