cc_mounts: correctly fallback to dd if fallocate fails (#585)
`create_swap()` was previously catching and not re-raising the
ProcessExecutionError that indicated swap creation failure; this meant
that the fallback logic could never be triggered.
This commit adds the required re-raise (as well as removing a duplicated
log message).
.travis.yml: add integration-tests to Travis matrix (#600)
This is implemented as a copy/paste of the `citest` integration testing
script: the two are not intended to co-exist long-term, so it isn't
worth further complicating an already complex part of our Travis
configuration for short-term code reuse.
The two changes from the `citest` definition: the test framework
executed on the last line of `script`, and it is given a `name` so we
can easily ignore failures.
The following commit merged all ssh keys into a default user file
`~/.ssh/authorized_keys` in sshd_config had multiple files configured for
AuthorizedKeysFile:
Multiple file fix for AuthorizedKeysFile config (#60)
This commit ignored the case when sshd_config would have a single file for
AuthorizedKeysFile, but a non default configuration, for example
`~/.ssh/authorized_keys_foobar`. In this case cloud-init would grab all keys
from this file and write a new one, the default `~/.ssh/authorized_keys`
causing the bug.
bddeb: new --packaging-branch argument to pull packaging from branch (#576)
bddeb builds a .deb package using the template packaging files in
packages/debian/.
The new --packaging-branch flag allows to specify a git branch
where to pull the packaging (i.e. the debian/ directory) from.
This is useful to build a .deb package from master with the very
same packaging which is used for the uploads.
DataSourceAzure: write marker file after report ready in preprovisioning (#590)
DataSourceAzure previously writes the preprovisioning
reported ready marker file before it goes through the
report ready workflow. On certain VM instances, the
marker file is successfully written but then reporting
ready fails.
Upon rare VM reboots by the platform, cloud-init sees
that the report ready marker file already exists.
The existence of this marker file tells cloud-init
not to report ready again (because it mistakenly
assumes that it already reported ready in
preprovisioning).
In this scenario, cloud-init instead erroneously
takes the reprovisioning workflow instead of
reporting ready again.