Last commit made on 2018-07-03
Get this branch:
git clone -b fix/boothook-documentation-typo https://git.launchpad.net/~tamsky/cloud-init
Only Marc Tamsky can upload to this branch. If you are Marc Tamsky please log in for upload directions.

Branch merges

Branch information


Recent commits

2d6d490... by Marc Tamsky <email address hidden> on 2018-07-03

fix documentation typo

be9ecc1... by Chad Smith on 2018-07-01

update_metadata: a datasource can support network re-config every boot

Very basic type definitions are now defined to distinguish 'boot'
events from 'new instance (first boot)'. Event types will now be handed
to a datasource.update_metadata method which can determine whether
to refresh its metadata and re-render configuration based on that
source event.

A datasource can 'subscribe' to an event by setting up the update_events
attribute on the datasource class which describe what config scope is
updated by a list of matching events. By default datasources will have
the following update_events: {'network': [EventType.BOOT_NEW_INSTANCE]}
This setting says the datasource will re-write network configuration only
on first boot of a new instance or when the instance id changes.

New methods are now present on the datasource:
  - clear_cached_attrs: Resets cached datasource attributes to values
    listed in datasource.cached_attr_defaults. This is performed prior to
    processing a fresh metadata process to avoid keeping old/invalid
    cached data around.
  - update_metadata: accepts source_event_types to determine if the
    metadata should be crawled again and processed

5858136... by Scott Moser on 2018-06-28

tests: drop salt-minion integration test

The salt minion integration test as we had it did not do a whole lot
more than the unit tests on that module did. Additionally, it caused
some transient failures at least in Ubuntu 18.04.

At a future date we may choose to add an integration test that installs
salt-minion and salt server and configures it to be a better test.

LP: #1778737

bb2cc5d... by Scott Moser on 2018-06-28

Retry on failed import of gpg receive keys.

When cloud-init tries to read a key from a keyserver, it will now
retry twice with 1 second in between each.

Retries of import are done by default because keyservers can be
unreliable. Additionally, there is no way to determine the difference
between a non-existant key and a failure. In both cases gpg (at least
2.2.4) exits with status 2 and stderr: "keyserver receive failed: No data"
It is assumed that a key provided to cloud-init exists on the keyserver so
re-trying makes better sense than failing.

Examples of things that made receive keys particularly unreliable:

There is also a change here from 'gpg --recv' to the longer
'gpg --recv-keys'. That option is functional and working back to
centos 6 (gpg 2.0.14) and ubuntu 14.04 (gpg 1.4.16).

c42a926... by Scott Moser on 2018-06-28

tools: Fix run-container when neither source or binary package requested.

If run-container was called without --package or --binary-package, then
it would still try to copy out artifacts and would fail doing so as
there were no artifacts to collect.

Also fix a bug when only --source-package without --package.

0db1745... by Oz Tiram on 2018-06-28

docs: Fix a small spelling error.

standargs -> standards.

7c88f96... by Scott Moser on 2018-06-26

tox: use simplestreams from git repository rather than bzr.

Simplestreams is moving to git. Use the git repo rather than bzr.

2d6e421... by Chad Smith on 2018-06-20

release 18.3

Bump the version in cloudinit/version.py to be 18.3 and update ChangeLog.

LP: #1777743

a670eb8... by Chad Smith on 2018-06-19

docs: represent sudo:false in docs for user_groups config module

4d69fb4... by Jacob Bednarz on 2018-06-19

Explicitly prevent `sudo` access for user module

To deny a user elevated access, you can omit the `sudo` key from the
`users` dictionary. This works fine however it's implicitly defined
based on defaults of `cloud-init`. If the project moves to have `sudo`
access allowed for all by default (quite unlikely but still possible)
this will catch a few people out.

This introduces the ability to define an explicit `sudo: False` in the
`users` dictionary and it will prevent `sudo` access. The behaviour is
identical to omitting the key.

LP: #1771468