| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Mapped from killermoehre
|
|
Map lp user kgarloff to github garloff
|
|
Avoid chpasswd on all the BSD variants.
|
|
|
|
Add support for additional escaping of formatting characters
in the YAML content between the 'cc:' and 'end_cc' tokens. On
s390x legacy terminals the use of square brackets [] are not
available limiting the ability to indicate lists of values in
yaml content. Using #5B and #5D, [ and ] respectively enables
s390x users to pass list yaml content into cloud-init via
command line interface.
|
|
|
|
Co-authored-by: Joshua Powers <josh.powers@canonical.com>
|
|
Currently, `cc_package_update_upgrade_install.py` fails because
`package_command()` does not know how to do an update on FreeBSD.
```
2020-03-23 20:01:53,995 - util.py[DEBUG]: Package update failed
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/cloud_init-20.1-py3.7.egg/cloudinit/config/cc_package_update_upgrade_install.py", line 85, in handle
cloud.distro.update_package_sources()
File "/usr/local/lib/python3.7/site-packages/cloud_init-20.1-py3.7.egg/cloudinit/distros/freebsd.py", line 158, in update_package_sources
["update"], freq=PER_INSTANCE)
File "/usr/local/lib/python3.7/site-packages/cloud_init-20.1-py3.7.egg/cloudinit/helpers.py", line 185, in run
results = functor(*args)
File "/usr/local/lib/python3.7/site-packages/cloud_init-20.1-py3.7.egg/cloudinit/distros/bsd.py", line 102, in package_command
cmd.extend(pkglist)
UnboundLocalError: local variable 'cmd' referenced before assignment
```
This commit defines a new `pkg_cmd_update_prefix` key. If it's empty, we
don't do any update, otherwise we use the value to update the package
manager.
|
|
|
|
* tools: use python3
Switch tools/ to use python3 instead of python. At minimum this
fixes building deb on python3 only releases like Focal. Applied
via shell commands:
$ grep 'usr/bin/.*python' tools/* 2>/dev/null | \
grep -v python3 | awk -F':' '{print $1}' | \
xargs -i sed -i -e '0,/python/s/python/python3/' {}
* Use /usr/bin/env python3 to be virtualenv friendly
|
|
Addresses "Runtime Error: dictionary keys changed during iteration".
Co-authored-by: Noah Meyerhans <noahm@debian.org>
LP: #1868327
|
|
These two implementations had drifted away from one another very
slightly. Reconcile them and then remove the one in cc_apt_configure.
|
|
On NetBSD and OpenBSD, the libc soname and location are different. There
is no reason to be to specific. Python is able to propely open the share
library by itself.
|
|
* test_oracle: sort imports
* DataSourceOracle: sort imports
|
|
Bring it into line with the current state of the code (by dropping the
now-untrue caveat).
|
|
These classes don't use `self.logs` anywhere in their body, so we can
remove the `with_logs = True` setting from them.
These instances were found using astpath[0], with the following
invocation:
astpath "//Name[@id='with_logs' and not(ancestor::ClassDef//Attribute[@attr='logs'])]"
[0] https://github.com/hchasestevens/astpath
|
|
Co-authored-by: Chad Smith <chad.smith@canonical.com>
|
|
|
|
Add support for rendering secondary static IPv4/IPv6 addresses on
any NIC attached to the machine. In order to see secondary IP
addresses in Ec2 IMDS network config, cloud-init now reads metadata
version 2018-09-24. Metadata services which do not support the Ec2
API version will not get secondary IP addresses configured.
In order to discover secondary IP address config, cloud-init now
relies on metadata API Parse local-ipv4s, ipv6s,
subnet-ipv4-cidr-block and subnet-ipv6-cidr-block metadata keys to
determine additional IPs and appropriate subnet prefix to set for a
nic.
Also add the datasource config option apply_full_imds_netork_config
which defaults to true to allow cloud-init to automatically configure
secondary IP addresses. Setting this option to false will tell
cloud-init to avoid setting up secondary IP addresses.
Also in this branch:
- Shift Ec2 datasource to emit network config v2 instead of v1.
LP: #1866930
|
|
The 'merged_cfg' key introduced in 71af48d was incorrectly referenced
to as 'ci_cfg' in the json validation test for ec2.
|
|
Quote the Ubuntu version numbers in releases.yaml to make sure they're
treated as strings and not as floats.
|
|
|
|
Drop remaining python six usage
|
|
This workflow will label pull requests with "stale-pr" if they haven't
seen activity for 14 days. It will then close them out after a further
7 days of inactivity.
|
|
(#251)
This is a follow-up to #144 which fixed the rendering behaviour.
While writing the tests, CI failed due to dict iteration differences across Python versions, so this also sorts output so that we will produce the same output across Python versions.
|
|
|
|
Since 94838def772349387e16cc642b3642020e22deda, CloudInit supports NetBSD
too.
|
|
Add support for the NetBSD Operating System.
Features in this branch:
* Add BSD distro parent class from which NetBSD and FreeBSD can
specialize
* Add *bsd util functions to cloudinit.net and cloudinit.net.bsd_utils
* subclass cloudinit.distro.freebsd.Distro from bsd.Distro
* Add new cloudinit.distro.netbsd and cloudinit.net.renderer for
netbsd
* Add lru_cached util.is_NetBSD functions
* Add NetBSD detection for ConfigDrive and NoCloud datasources
This branch has been tested with:
- NoCloud and OpenStack (with and without config-drive)
- NetBSD 8.1. and 9.0
- FreeBSD 11.2 and 12.1
- Python 3.7 only, because of the dependency oncrypt.METHOD_BLOWFISH.
This version is available in NetBSD 7, 8 and 9 anyway
|
|
See the added comment for details.
|
|
|
|
The list so far is partial.
|
|
Instead of using the username that triggered the action (which, in the
case of a committer merging master into a PR branch will be the
committer), always use the username of the submitter of the pull
request.
|
|
Now that we can distinguish between CI xenial dependencies and
needed-to-run-on-dev-machine xenial depedencies, we can return to
testing with the correct jsonpatch version.
|
|
Github api doesn't allow read-write access to labels or comments when
running from a pull_request fork during CI.
This restriction results in an API error
message: "Resource not accessible by integration"
If we want to run this action per pull_request, we need to convert the
action to fail the PR status check and emit the required steps to sign the
CLA to the console on the PR's failed status tab.
|
|
pyflakes versions older than 2.1.0 are incompatible with Python 3.8
(which is the Python version in the current Ubuntu development release).
See https://github.com/PyCQA/pyflakes/issues/367 for details.
2.1.1 is the latest version ATM, so bump to that.
|
|
As the nose docs[0] themselves note, it has been in maintenance mode for the past several years. pytest is an actively developed, featureful and popular alternative that the nose docs themselves recommend. See [1] for more details about the thinking here.
(This PR also removes stale tox definitions, instead of modifying them.)
[0] https://nose.readthedocs.io/en/latest/
[1] https://lists.launchpad.net/cloud-init/msg00245.html
|
|
Cloud-config userdata provided as jinja templates are now distro,
platform and merged cloud config aware. The cloud-init query command
will also surface this config data.
Now users can selectively render portions of cloud-config based on:
* distro name, version, release
* python version
* merged cloud config values
* machine platform
* kernel
To support template handling of this config, add new top-level
keys to /run/cloud-init/instance-data.json.
The new 'merged_cfg' key represents merged cloud config from
/etc/cloud/cloud.cfg and /etc/cloud/cloud.cfg.d/*.
The new 'sys_info' key which captures distro and platform
info from cloudinit.util.system_info.
Cloud config userdata templates can render conditional content
based on these additional environmental checks such as the following
simple example:
```
## template: jinja
#cloud-config
runcmd:
{% if distro == 'opensuse' %}
- sh /custom-setup-sles
{% elif distro == 'centos' %}
- sh /custom-setup-centos
{% elif distro == 'debian' %}
- sh /custom-setup-debian
{% endif %}
```
To see all values: sudo cloud-init query --all
Any keys added to the standardized v1 keys are guaranteed to not
change or drop on future released of cloud-init. 'v1' keys will be retained
for backward-compatibility even if a new standardized 'v2' set of keys
are introduced
The following standardized v1 keys are added:
* distro, distro_release, distro_version, kernel_version, machine,
python_version, system_platform, variant
LP: #1865969
|
|
The EC2 Data Source needs to handle 3 states of the Instance
Metadata Service configured for a given instance:
1. HttpTokens : optional & HttpEndpoint : enabled
Either IMDSv2 or IMDSv1 can be used.
2. HttpTokens : required & HttpEndpoint : enabled
Calls to IMDS without a valid token (IMDSv1 or IMDSv2 with expired token)
will return a 401 error.
3. HttpEndpoint : disabled
The IMDS http endpoint will return a 403 error.
Previous work to support IMDSv2 in cloud-init handled case 1 and case 2.
This commit handles case 3 by bypassing the retry block when IMDS returns HTTP
status code >= 400 on official AWS cloud platform.
It shaves 2 minutes when rebooting an instance that has its IMDS http token endpoint
disabled but creates some inconsistencies. An instance that doesn't set
"manual_cache_clean" to "True" will have its /var/lib/cloud/instance symlink
removed altogether after it has failed to find a datasource.
|
|
When cloud-init persisted instance metadata to instance-data.json
if failed to redact the sensitive value. Currently, the only sensitive
key 'security-credentials' is omitted as cloud-init does not fetch
this value from IMDS.
Fix this by properly redacting the content from the public
instance-metadata.json file while retaining the value in the root-only
instance-data-sensitive.json file.
LP: #1865947
|
|
Allow disabling cloud-init's network configuration via a plain-text kernel cmdline
Cloud-init docs indicate that users can disable cloud-init networking via kernel
command line parameter 'network-config=<YAML>'. This does not work unless
the <YAML> payload base64 encoded. Document the base64 encoding
requirement and add a plain-text value for disabling cloud-init network config:
network-config=disabled
Also:
- Log an error and ignore any plain-text network-config payloads that are
not specifically 'network-config=disabled'.
- Log a warning if network-config kernel param is invalid yaml but do not
raise an exception, allowing boot to continue and use fallback networking.
LP: #1862702
|
|
Our header redact logic was redacting both logged request headers and
the actual source request. This results in DataSourceEc2 sending the
invalid header "X-aws-ec2-metadata-token-ttl-seconds: REDACTED" which
gets an HTTP status response of 400.
Cloud-init retries this failed token request for 2 minutes before
falling back to IMDSv1.
LP: #1865882
|
|
|
|
one line doc fix
|
|
In cloud-init 19.2, we added the ability for cloud-init to detect
OpenStack platforms by checking for "OpenStack Compute" or "OpenStack
Nova" in the chassis asset tag. However, this was never reflected
in the documentation. This patch updates the datasources documentation
for OpenStack to reflect the possibility of using the chassis asset tag.
LP: #1669875
|
|
* Add physical network type: cascading to openstack helpers
* add new helpers test for checking all openstack KNOWN_PHYSICAL_TYPES get type 'physical'.
|
|
|
|
Bump the version in cloudinit/version.py to 20.1 and
update ChangeLog.
LP: #1863954
|
|
* tools/read-version: don't enforce version parity in release branch CI
We have a bootstrapping problem with new releases, currently. To take
the example of 20.1: the branch that bumps the version fails CI because
there is no 20.1 tag for it to use in read-version. Previously, this
was solved by creating a tag and pushing it to the cloud-init repo
before the commit landed. However, we have GitHub branch protection
enabled, so the commit that needs to be tagged is not created until the
pull request lands in master.
This works around this problem by introducing a very specific check: if
we are performing CI for an upstream release branch, we skip the
read-version checking that we know will fail.
* tools/make-tarball: add --version parameter
When using make-tarball as part of a CI build of a new upstream release,
the version it determines is inconsistent with the version that other
tools determine. Instead of encoding the logic here (as well as in
Python elsewhere), we add a parameter to allow us to set it from outside
the script.
* packages/bddeb: handle missing version_long in new version CI
If we're running in CI for a new upstream release, we have to use
`version` instead of `version_long` (because we don't yet have the tag
required to generate `version_long`).
|
|
Instead of logging the token values used log the headers and replace the actual
values with the string 'REDACTED'. This allows users to examine cloud-init.log
and see that the IMDSv2 token header is being used but avoids leaving the value
used in the log file itself.
LP: #1863943
|
