* 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
Change-Id: I9ffd85645563192b5d6124f8dbb71c24245eefc4
According to [1] _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.
[1] http://docs.openstack.org/developer/oslo.i18n/guidelines.html
Change-Id: Ib9f92ef6696b9a95ddae74f0d4a0a557c06ecc91
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.
Change-Id: I89e86d00993d51e2514b1e589503c6d966909403
Partial-Bug: #1375864
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
Closes-Bug: #1325313
Change-Id: I365f3d882b8f64f9710eea4901ac266f9fcf0da3
Updated a set of files to add missing translation support in the
log messages.
Change-Id: I58d561c5e1ecff550483ee0be696999e927c98ad
Partial-Bug: #1321283
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.
Closes-Bug: #1257410
Change-Id: I42dda36045f79be079b2030669284e9db71463d7
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)
Change-Id: Ie9838dba11323575165fc3bfdfbd0d0b93f653fa
This is a first step towards fixing #1257410 as outlined in the bug
report.
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.
Change-Id: Ife4fec99650341de698eb51741d96f95de00dcf0
Partial-Bug: #1257410
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.
Change-Id: I42f802c7994b8d907f0cc4e3b1a38e6fd89dac0c
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.
Change-Id: Ic26bffb17b1870d656fea72cf3da3dfe2b7f44d0
Closes-Bug: #1263297
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.
Change-Id: I5426fdad3031f91b4b9c1f9c9c19ac9cc42cf2dd
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
to 0.7.
This reverts commit 621f5bfdba.
Fixes: Bug #1207088
Change-Id: If80863883afee28bdde6dd506826ec5710cc0308
part-handler.py was acting as a write-files mechanism. Instead just
use the write-files mechanism directly to avoid the complexities of
the part-handler.
blueprint: use-cloudinit-write
Change-Id: I6e80c344743d6fd2fa9a49507de6d50e3d9eea73
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.
Change-Id: Id0312bd2216a83753df601b17ad16d5355cdb11d
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
Change-Id: Ica2dbe63d9dcbce8bb8de298eba452c34ab173d9
the cc_ssh script already executes in cloud config without being
explicitly called. As it is now, it is executing twice.
Make it execute only once.
Change-Id: I2d53adbea0175f63db71be516639d40aa0f8a1de
- log the exceptions so the user can diagnose issues.
bug 1154641
Change-Id: Ic085c9f062255a9fa44b3e31b464c9ebd19a947c
Signed-off-by: Angus Salkeld <asalkeld@redhat.com>
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
by cloud-init.
For the moment, the part handler will continue to write to
/var/lib/cloud/data to be removed at a later date.
Change-Id: I70b714c70ed146d4f6807850d6e7264c6a4624cd
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.
Change-Id: I04e773a743ec210e90394e50d2bb70c70664e80e
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.)
Change-Id: Ibcaf310a5e4ff9a9ed8b1065bdd411e1b95d4de5
Signed-off-by: Jeff Peeler <jpeeler@redhat.com>
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-Id: I27129f8ae6144ae7172b7159ed70fc5f0d7d07b9
Change loguserdata script to python to allow easy detection of which
version of cloud-init installed. Some logging was added to
part-handler.
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
Change-Id: I9005a21bfb74f27208f9195a6e10e1d2b474e91f
Signed-off-by: Jeff Peeler <jpeeler@redhat.com>
Can't use colon builtin apparently, or you'll get this:
/var/lib/cloud/instance/scripts/runcmd: line 2:
{setenforce 0 > /dev/null 2>&1 ||:: No such file or directory
Added cloud-init debug output to get the above, copied from:
http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config-chef.txt
Change-Id: I341cf73bc9a0f843d7ab8c99a9d15e1d514654e7
Signed-off-by: Jeff Peeler <jpeeler@redhat.com>
Sirushti Murugesan