azure: case-insensitive UUID to avoid new IID during kernel upgrade
Kernel's newer than 4.15 present /sys/dmi/id/product_uuid as a
lowercase value. Peviously UUID as uppercase.
Azure datasource reads the product_uuid directly as their platform's
instance-id. This present a problem if a kernel is either
upgraded or downgraded across the 4.15 kernel version boundary because
the case of the UUID will change, resulting in cloud-init seeing a
"new" instance id and re-running all modules.
This causes ssh host keys to get regenerated across reboot into the new
kernels which will cause concern on long-running instances that something
nefarious has happened.
Actually "@includedir" is the modern syntax, and "#includedir" the historic
syntax. It has been considered that "#includedir" was too puzzling because
it started with a "#" that otherwise denotes comments.
This happens to be the default in SUSE Linux enterprise sudoer package,
so cloudinit should take this into account.
Otherwise, cloudinit was adding an extra #includedir, which was
resulting on the files under /etc/sudoers.d being included twice, one by
@includedir from the SUSE package, one by the @includedir from
cloudinit. The consequence of this, was that if you were defining an
Cmnd_Alias inside any of those files, this was being defined twice and
creating an error when using sudo.
upstream/20.4.1 was used to release the 20.4.1 hotfix. Merging it into
master reconciles that fork in history, and integrates both the 20.4.1
changelog and tag into our main history.
6efe16d...
by
xiaofengw-vmware <email address hidden>
[VMware] change default max wait time to 15s (#774)
If cloud-init is enabled on VMware platform, cloud-init will wait until
its configuration file is ready and currently the max wait is 90
seconds by default. With our test, this configuration file should be
ready within 1 second, so change it to 15 seconds for better
performance. Also update the documentation about how to change the
default value in cloud-init configuration file.
The tox pylint command was failing because of competing dependencies in
the multiple requirements files. Given that we plan on no longer
updating cloud_tests, we also no longer need to lint them.
