By default, ubuntu trusty images has python3 executable in
path, but we can't use that for executing loguserdata script,
because pkg_resources can't be imported. Now it's proposed to
try importing pkg_resources for validating readiness of
python3 for executing this script. If pkg_resources can't be
imported there is no other choice except using python2.
Now we can fail while trying to get the version of cloud-init
via pkg_resources. Try to get the version via ordinary cmd call
* Use six.moves.reduce
* Update numliteral from 0L to 0
* Use open() instead of file()
* Use rich comparison methods instead of cmp()
partial blueprint heat-python34-support
According to  _LI() should be used for LOG.info(), _LE() for
LOG.exception() and LOG.error(), _LW() for LOG.warning().
The log marker functions must only be used when the message is
sent directly to the log.
Debug level log messages should not be translated.
The loguserdata.py file gets uploaded to the servers created by Heat to run
under cloud-init. Since the default versions of Python installed on the
user's server may be very old (e.g. RHEL 5 defaults to Python 2.4), avoid
using the octal syntax introduced for Python 3.0 and backported only as far
as Python 2.6. (Also avoid the old syntax, which will break on Python 3.x.)
Also remove use of the "with" statement from loguserdata.py and
part-handler.py. This statement is only available from Python 2.6 on (or in
Python 2.5 via "from __future__ import with_statement").
Finally, remove use of the "except ExceptionType as value" syntax for
catching exceptions. Again, this was only backported to Python 2.6.
The logs in loguserdata don't need to be translated because it's sent
with the po files to instances, and actually break because of gettext
not being used
When the the instance_user value from heat.conf is set to empty string/None and
the user doesn't specify Server's admin_user property, Heat will not create a
custom cloud-init user.
The instance_user config option and admin_user property are deprecated and will
be removed in Juno where this behaviour becomes the default.
AWS::EC2::Instance will still create a cloud-init user for CloudFormation
compatibility. In the absence of the instance_user config option, 'ec2-user'
will be used.
This patch is one in a series to re-enable H306 style check rule
(imports are in alphabetical order). It touches common and cloudinit files.
Implements: blueprint reduce-flake8-ignored-rules (partial)
This is a first step towards fixing #1257410 as outlined in the bug
Disabling SELinux is not necessary, but the fact that we're using both
the `user` directive in cloudinit/config and `useradd` in boothook.sh
is a bit confusing so this documents the reasons for both.
Some images/distros do not install/use selinux. This small change will
verify that `setenforce` is executable and in the path before attempting
to run the command. This prevents the script from erroring and causing a
failed `cloud-init` run.
In the past it may have been necessary to do this but it causes problems
for users of advanced features. We should be able to operate with the
default OS configuration of cloud-init.
Images which have heat-cfntools installed from rpm or deb
will not have cfn tool links in /opt/aws/bin.
This change runs cfn-create-aws-symlinks during cloud-init
boothook.sh. It should do the following:
* if no cfn tools exist in /opt/aws/bin, symlinks from /usr/bin
will be created
* if cfn tools exist in /opt/aws/bin, no symlinks are created
* if cfn-create-aws-symlinks doesn't exist, there will be no effect
This is required to use a vanilla Fedora 20 cloud image with heat,
which has heat-cfntools pre-installed.
Ubuntu has 0.6 of cloudinit, and write-files doesn't work on that
distro. Ubuntu does not intend to update cloudinit in their LTS release
This reverts commit 621f5bfdba.
Fixes: Bug #1207088
part-handler.py was acting as a write-files mechanism. Instead just
use the write-files mechanism directly to avoid the complexities of
Python logging is configured with a stream handler and should
also replicate the previous logging to 0600 /var/log/heat-provision.log
By logging to a stream handler cloud-init will write to its log,
which will show up in the server console log. This means that heat
provisioning can now be monitored without needing to log in with:
nova console-log <servername>
This change also touches the file /var/lib/heat-cfntools/provision-finished
instead of also writing a datestamp to it, which is redundant.
Previously user ids of new instances were limited to ec2-user.
This patch adds a new configuration option to be placed in
/etc/heat/heat-engine.conf called "default_instance_user" which
allows the default of ec2-user to be overriden.
Note for reviewers that runcmd does not work properly. It was
actually running after the loguserdata.py script finished execution.
Fixes: Bug #1101347
The /var/lib/heat-cfntools directory should be owned by the
heat-cfntools package for whichever distro it is included.
This avoids the problem of heat writing to directories owned
For the moment, the part handler will continue to write to
/var/lib/cloud/data to be removed at a later date.
Fixes: Bug #1105806
- Use distutils.version.LooseVersion for cloud-init version check
- Fix bug 1100287 by setting the following modes:
- 0600 /var/log/heat-provision.log
- 0700 /var/lib/heat
- 0700 /var/lib/cloud/data/cfn-userdata (was 0111!)
- Full test coverage except for where __name__ == '__main__'
- File size has gone from 1218 bytes to 1636. If necessary we could reduce size in the future by using short names
This works for me when launching a template. At least if there are any regressions they can have a test written for the fix.
A recent change removed the use of the cloudinit module, so write this
log to /var/lib/heat. Functional test paths updated as well.
(User data injection was removed, so that has been deleted as well.)
Signed-off-by: Jeff Peeler <firstname.lastname@example.org>
Previously the present of an API call only present in cloud-init 0.6.x
was used to determine whether or not cfn-userdata would have been executed
or not. The API call was removed in 0.7.x. This Fixes bug #1103793
Change loguserdata script to python to allow easy detection of which
version of cloud-init installed. Some logging was added to
Took out injecting the command to touch provision-finished in the user
data. This is now handled in loguserdata.py.
Note that up until cloud-init version 0.6.0, the user data is not
passed to part-handler. This behavior is why it's not possible to log
the provisioning process with older versions. (Technically could rely
on the redirection support added post 0.6.0, but having a separate
file just for provisioning seems beneficial.)
fixes bug 1072921
Signed-off-by: Jeff Peeler <email@example.com>