| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Distributions other than RHEL also use /usr/lib/udev for the rules
path. Instead of hardcoding the udev rules path for RedHat, check
pkg-config for the proper location.
|
| |
|
|
|
|
| |
For distros that still use sysvinit, these files are getting
updated to support kernel commandline disablement.
Suse no longer uses sysvinit, so they may be removed
instead.
|
| |
|
|
|
|
|
|
|
| |
At inception[1], dhclient hooks were used to filter environment variables into /run/cloud-init/dhclient.hooks/<interface>.json which was consumed by WALinuxAgentShim. The fallback method was to parse the dhcp client lease file.
Today the Azure datasource directly uses the parsed lease file[2], and loading /run/cloud-init/dhclient.hook/<interface>.json file was removed in 22.2[3]. With no other consumers, we can remove this.
[1] https://github.com/canonical/cloud-init/commit/648dbbf6b090c81e989f1ab70bf99f4de16a6a70
[2] https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/DataSourceAzure.py#L447
[3] https://github.com/canonical/cloud-init/commit/5ad0768a796bc07232476d0d29b5225f1e6e131c
|
| |
|
|
|
|
|
|
|
|
|
| |
Use 'git describe <branch>' as the version number, even if the version
differs from what is in version.py. This means that if the most recent
commit is a tag, we'll get the tag number, otherwise we'll also show
the number of commits since the last tag on the branch.
Fix setup.py to align with PEP 440 versioning replacing trailing
hyphen beyond major.minor.patch-g<HASH> with a "+".
Additionally, did some cleanup and typing fixes on the script.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
cloud-init clean command provides a run-parts /etc/cloud/clean.d
directory to allow third party apps to deliver supplemental cleanup
scripts to aid in golden image creation.
Any executable scripts in /etc/cloud/clean.d will be run in
lexicographical order via subp.runparts.
This aids customers creating golden images, where the typical process
an image creator performs is to reset cloud-init on that system so
the next boot of this cloned image will be treated as first-boot and
perform all early system configuration.
|
| |
|
|
|
|
|
| |
RHEL must put cloudinit .rules files in /usr/lib/udev/rules.d
This place is a rhel standard and since it is used by all packages
cannot be modified.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
|
| |
|
|
|
|
| |
- Remove references and dead code to Xenial, Eoan, Python < 3.7
- cc_ubuntu_drivers: Use python3-debconf instead of shell script
- add integration test for ubuntu_drivers
- bump pycloudlib for OCI subnet/jammy fixes
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
upstream cloud-init not longer publishes to distribution
versions which support upstart.
Trusty has not been receiving cloud-init updates since
0.7.5 and Xenial stopped getting updates as version 21.1.
Even though Ubuntu Xenial's default init system is systemd
there was still an option for folks to launch amd maintain
images which relied on upstart. Now that Xenial no longer has
updates from upstream cloud-init we can drop all upstart
support.
Old Fedora and RHEL releases which use upstart are also not
receiving cloud-init updates from tip of main.
|
| |
|
|
|
|
|
| |
Changes:
- pylint 2.13.8: fix E0601(used-before-assignment)
- pylint 2.13.8: fix E4702(modified-iterating-dict)
- pylint 2.13.8: silence W0402(deprecated-module) on distutils.errors
- tox: bump linters versions
|
| |
|
|
| |
- move datasource helpers to dedicated directory
- drop unnecessary executable bit on shebangless python files
|
| |
|
|
|
|
|
|
| |
- add type stubs for mypy: jsonschema, oauthlib
- specify mypy directories to avoid env/ false positive
- add conftest.py and setup.py
- make setup.py pass pylint:
- check ./tools/render-cloudcfg return code in setup.py
- find_sources() has no return code, don't check for one
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Package a single JSON schema file for user-data validation at
cloudinit/config/cloud-init-schema.json.
Perform validate_cloudconfig_schema call to just after the
user-data is consumed. This will allow single validation of all
user-data against the full schema instead of
repetitive validatation calls against each cloud-config module
(cloudinit.config.cc_*) sub-schemas.
This branch defines the simple apt_pipelining schema and
migrates existing cc_apk_configure into cloud-init-schema.json.
The expectation will be additional branches to migrate from legacy
"schema" attributes inside each cloud-config module toward unique
cc_<module_name> definitions in the global shema file under "$defs"
of cloud-init-schema-X.Y..json.
Before legacy sub-schema definitions are migrated the following
funcs grew support to read sub-schemas from both static
cloud-init-schema.json and the individual cloud-config module
"schema" attributes:
- get_schema: source base schema file from cloud-init-schema.json
and supplement with all legacy cloud-config module "schema" defs
- get_meta_doc: optional schema param so cloud-config modules
no longer provide the own local sub-schemas
- _get_property_doc: render only documentation of sub-schema based
on meta['id'] provided
- validate_cloudconfig_schema: allow optional schema param
Additionally, fix two minor bugs in _schemapath_for_cloudconfig:
- `cloud-init devel schema --annotate` which results in a Traceback
if two keys at the same indent level have invalid types.
- exit early on empty cloud-config to avoid a Traceback on the CLI
|
| |
|
|
|
|
|
|
|
|
| |
distutils is getting deprecated soon. Let's replace it with suggested
alternatives as suggested in:
https://www.python.org/dev/peps/pep-0632/
Remove `requests` version check and related code from url_helper.py
as the versions specified are old enough to no longer be relevant.
Signed-off-by: Shreenidhi Shedi <sshedi@vmware.com>
|
| |
|
|
|
| |
Applied Black and isort, fixed any linting issues, updated tox.ini
and CI.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This attempts to standardize unit test file location under test/unittests/
such that any source file located at cloudinit/path/to/file.py may have a
corresponding unit test file at test/unittests/path/to/test_file.py.
Noteworthy Comments:
====================
Four different duplicate test files existed:
test_{gpg,util,cc_mounts,cc_resolv_conf}.py
Each of these duplicate file pairs has been merged together. This is a
break in git history for these files.
The test suite appears to have a dependency on test order. Changing test
order causes some tests to fail. This should be rectified, but for now
some tests have been modified in
tests/unittests/config/test_set_passwords.py.
A helper class name starts with "Test" which causes pytest to try
executing it as a test case, which then throws warnings "due to Class
having __init__()". Silence by changing the name of the class.
# helpers.py is imported in many test files, import paths change
cloudinit/tests/helpers.py -> tests/unittests/helpers.py
# Move directories:
cloudinit/distros/tests -> tests/unittests/distros
cloudinit/cmd/devel/tests -> tests/unittests/cmd/devel
cloudinit/cmd/tests -> tests/unittests/cmd/
cloudinit/sources/helpers/tests -> tests/unittests/sources/helpers
cloudinit/sources/tests -> tests/unittests/sources
cloudinit/net/tests -> tests/unittests/net
cloudinit/config/tests -> tests/unittests/config
cloudinit/analyze/tests/ -> tests/unittests/analyze/
# Standardize tests already in tests/unittests/
test_datasource -> sources
test_distros -> distros
test_vmware -> sources/vmware
test_handler -> config # this contains cloudconfig module tests
test_runs -> runs
|
| | |
|
| |
|
|
|
|
|
| |
In some cloud-init enabled images the sshd-keygen@.service
may race with cloud-init and prevent ssh host keys from being
generated or generating host keys twice slowing boot and consuming
additional entropy during boot. This drop-in unit adds a condition to
the sshd-keygen@.service which prevents running if cloud-init is active.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using flake8 inplace of pyflakes
Renamed run-pyflakes -> run-flake8
Changed target name to flake8 in Makefile
With pyflakes we can't suppress warnings/errors in few required places.
flake8 is flexible in that regard. Hence using flake8 seems to be a
better choice here.
flake8 does the job of pep8 anyway.
So, removed pep8 target from Makefile along with tools/run-pep8 script.
Included setup.py in flake8 checks
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a udev script which will invoke a hotplug hook script on all net
add events. The script will write some udev arguments to a systemd FIFO
socket (to ensure we have only instance of cloud-init running at a
time), which is then read by a new service that calls a new 'cloud-init
devel hotplug-hook' command to handle the new event.
This hotplug-hook command will:
- Fetch the pickled datsource
- Verify that the hotplug event is supported/enabled
- Update the metadata for the datasource
- Ensure the hotplugged device exists within the datasource
- Apply the config change on the datasource metadata
- Bring up the new interface (or apply global network configuration)
- Save the updated metadata back to the pickle cache
Also scattered in some unrelated typing where helpful
|
| |
|
|
|
|
|
| |
- Mostly based on FreeBSD, the main exception is that
`find_devs_with_on_freebsd` does not work.
- Since we cannot get the CDROM or the partition labels,
`find_devs_with_on_dragonflybsd()` has a more naive approach and
returns all the block devices.
|
| |
|
|
| |
We no longer need to support versions which don't have
subprocess.check_output, so we can rely on its presence in the stdlib.
|
| |
|
|
|
| |
- tested on OpenBSD 6.6
- tested on OpenStack without config drive, and NoCloud with ISO config
drive
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
Parse /etc/system-release-cpe to detect Amazon Linux and set the proper value.
|
| |
|
|
|
| |
Per lintian, this is the path at which bash completion scripts should
now be installed.
|
| |
|
|
|
|
| |
The systemd generator used had a hard coded path for the location target
file to create. This path does not apply to all distributions.
Make the generator and template to have the path set during build time.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add a quick cloud lookup utility in order to more easily determine
the cloud on which an instance is running.
The utility parses standardized attributes from
/run/cloud-init/instance-data.json to print the canonical cloud-id
for the instance. It uses known region maps if necessary to determine
on which specific cloud the instance is running.
Examples:
aws, aws-gov, aws-china, rackspace, azure-china, lxd, openstack, unknown
|
| |
|
|
|
|
|
|
|
| |
Allow the user to set the distribution with --distro argument to setup.py.
Fall back is to read /etc/os-release. Final backup is to use
platform.dist() Python function. The platform.dist() function is
deprecated and will be removed in Python 3.7
LP: #1745235
|
| |
|
|
|
| |
In bash shells with bash_completion enabled, now the cloud-init
sub commands and parameters/flags will be shown.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cloud-init renders template files during its run of setup.py.
Those rendered files were in a temp dir and were making their
way into the SOURCES.txt file. That caused problems for SuSE's build
system that desired for reproducible builds.
https://reproducible-builds.org/
We do not want to include those, so here we explicitly prune them out.
The issue of SOURCES.txt containing tmp files was reproducible with:
$ rm -Rf cloud_init.egg-info
$ git clean --force
$ rm -Rf ../root.d; python3 setup.py install --root=../root.d
$ grep ^tmp cloud_init.egg-info/SOURCES.txt
goo: http://bugzilla.opensuse.org/show_bug.cgi?id=1069635
|
| |
|
|
|
|
|
|
|
|
|
| |
Here we commit the SuSE provided sysvinit scripts. They are very similar
to those in redhat/ directory. They differ in small but important ways.
Rather than build a template system here we will just accept the copy
and paste. sysvinit in both RedHat and SuSE is EOL, so we do not
expect any real maintenance cost here.
LP: #1718649
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert "centos: do not package systemd-fsck drop-in."
Revert "systemd: make systemd-fsck run after cloud-init.service"
The systemd-fsck drop-in caused regressions by introducing ordering
The change reverts the original commit that added systemd-fsck drop-in
and another commit that had removed that from the centos packaging:
1f5489c258a26f4e26261c40786537951d67df1e
8a5296c41db45be3a172862f324ad44e732a2250
The result is to no longer provide the systemd-fsck drop-in.
LP: #1717477
|
| |
|
|
|
|
|
|
|
|
|
| |
The ubuntu-init-switch module allowed the use to launch an instance that
was booted with upstart and have it switch its init system to systemd and
then reboot itself. It was only useful for the time period when Ubuntu was
transitioning to systemd but only produced images using upstart.
Also, do not run setup with --init-system=upstart. This means that by
default, debian packages built with packages/bddeb will not have upstart
unit files included. No other removal is done here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is not yet called, but will be called in a subsequent Ec2-related branch to manually initialize a network interface with the responses using dhcp discovery without any dhcp-script side-effects. The functionality has been tested on Ec2 ubuntu and CentOS vms to ensure that network interface initialization works in both OS-types.
Since there was poor unit test coverage for the cloudinit.net.__init__ module, this branch adds a bunch of coverage to the functions in cloudinit.net.__init. We can also now have unit tests local to the cloudinit modules. The benefits of having unittests under cloudinit module:
- Proximity of unittest to cloudinit module makes it easier for ongoing devs to know where to augment unit tests. The tests.unittest directory is organizated such that it
- Allows for 1 to 1 name mapping module -> tests/test_module.py
- Improved test and module isolation, if we find unit tests have to import from a number of modules besides the module under test, it will better prompt resturcturing of the module.
This also branch touches:
- tox.ini to run unit tests found in cloudinit as well as include all test-requirements for pylint since we now have unit tests living within cloudinit package
- setup.py to exclude any test modules under cloudinit when packaging
|
| |
|
|
|
|
|
|
|
|
|
| |
cloud-init.service may write filesystems (fs_setup) or re-partition
(disk_setup) disks.
If systemd-fsck is running on a device while that is occuring
then the partitioning or mkfs might fail due to the device being busy.
Alternatively, the fsck might fail and cause subsequent mount to fail.
LP: #1691489
|
| |
|
|
|
|
| |
Under el7, cloud-init systemd files need some unit tweaks to ensure
they run at the right time. Pull in current el7 downstream systemd unit
changes.
|
| |
|
|
|
|
| |
Cloud-init's template renderer does not require the use of cheetah
(which is python2 only) so do not put it in the list of package
requirements.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here we move the config/cloud.cfg to be rendered as a template.
That allows us to maintain deltas between distros in one place.
Currently we use 'variant' variable to make decisions.
A tools/render-cloudcfg is provided to render the file.
There were changes to setup.py, MANIFEST.in to allow us to put all
files into a virtual env installation and to render the cloud-config
file in 'install' or 'bdist' targets.
We have also included some config changes that were found in the
redhat distro spec.
* include some config changes from the redhat distro spec.
The rendered cloud.cfg has some differences.
Ubuntu: white space and comment changes only.
Freebsd:
- whitespace changes and comment changes
- datasource_list definition moved to be closer to 'datasource'.
- enable modules: migrator, write_files
- move package-update-upgrade-install to final.
The initial work was done by Josh Harlow.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch targets to make FreeBSD 10.3 or 11 work on Azure. The
modifications abide by the rule of:
* making as less modification as possible
* delegate to the distro or datasource where possible.
The main modifications are:
1. network configuration improvements, and movement into distro path.
2. Fix setting of password.
Password setting through "pw" can only work through pipe.
3. Add 'root:wheel' to syslog_fix_perms field.
4. Support resizing default file system (ufs)
5. copy cloud.cfg for freebsd to /etc/cloud/cloud.cfg rather than
/usr/local/etc/cloud/cloud.cfg.
6. Azure specific changes:
a. When reading the azure endpoint, search in a different path
and read a different option name (option-245 vs. unknown-245).
so, the lease file path should be generated according to platform.
b. adjust the handling of ephemeral mounts for ufs filesystem and
for finding the ephemeral device.
c. fix mounting of cdrom
LP: #1636345
|
| |
|
|
|
|
|
| |
Add a basic snapcraft.yaml file to allow the execution of cloud-init as
a snap. This will always pull down the latest source from master for
the snap. setup.py will now also set the default init system to be
systemd when no other is passed to it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ds-identify is run here from the generator. If ds-identify does
not see any datasources, it can completely disable cloud-init.
The big value in this is that if there is no datasource, no python
will ever be loaded, and cloud-init will be disabled.o
The default policy being added here is:
search,found=all,maybe=all,notfound=disabled
That means:
- enable (in 'datasource_list') all sources that are found.
- if none are found, enable all 'maybe'.
- if no maybe are found, then disable cloud-init.
On platforms without DMI (everything except for aarch64 and x86),
the default 'notfound' setting is 'enabled'. This is because many of
the detection mechanisms rely on dmi data, which is present only on
x86 and aarch64.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has been a recurring ask and we had initially just made the change to
the cloud-init 2.0 codebase. As the current thinking is we'll just
continue to enhance the current codebase, its desirable to relicense to
match what we'd intended as part of the 2.0 plan here.
- put a brief description of license in LICENSE file
- put full license versions in LICENSE-GPLv3 and LICENSE-Apache2.0
- simplify the per-file header to reference LICENSE
- tox: ignore H102 (Apache License Header check)
Add license header to files that ship.
Reformat headers, make sure everything has vi: at end of file.
Non-shipping files do not need the copyright header,
but at the moment tests/ have it.
|
| |
|
|
|
|
| |
Adds an install option for for OpenRC init scripts.
I've also restricted installing tests more correctly.
Also, don't hardcode the path to ip (/bin/ip on gentoo).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is more efficient and cross-distribution safe to use the hooks function
from dhclient to obtain the Azure endpoint server (DHCP option 245).
This is done by providing shell scritps that are called by the hooks
infrastructure of both dhclient and NetworkManager. The hooks then
invoke 'cloud-init dhclient-hook' that maintains json data
with the dhclient options in
/run/cloud-init/dhclient.hooks/<interface>.json .
The azure helper then pulls the value from
/run/cloud-init/dhclient.hooks/<interface>.json file(s). If that file does
not exist or the value is not present, it will then fall back to the
original method of scraping the dhcp client lease file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Modification of the tarball became problematic, as it meant that
any tool extracting source would find the orig source tarball different.
I found this unusable when trying to use 'gbp buildpackage'.
Other changes here are to better support using python3 or python2
for the build. Makefile will try to call the right python version
and can be told which python to use.
read-version: by adding 'tiny_p' and avoiding the import of
cloudinit.util, we need less dependencies to run this.
|
| |
|
|
| |
This allows for the test_cli test to be more sane.
|
| |\ |
|
| | |
| |
| |
| |
| | |
This didn't really work. See bug for more info.
LP: #1577844
|
| |\ \
| |/
|/| |
|
| | | |
|
