| Age | Commit message (Collapse) | Author |
|---|
|
Add DataSourceLXD which knows how to talk to the dev-lxd socket to
obtain all instance metadata API:
https://linuxcontainers.org/lxd/docs/master/dev-lxd.
This first branch is to deliver feature parity with the existing
NoCloud datasource which is currently used to intialize LXC instances
on first boot.
Introduce a SocketConnectionPool and LXDSocketAdapter to support
performing HTTP GETs on the following routes which are surfaced by the
LXD host to all containers:
http://unix.socket/1.0/meta-data
http://unix.socket/1.0/config/user.user-data
http://unix.socket/1.0/config/user.network-config
http://unix.socket/1.0/config/user.vendor-data
These 4 routes minimally replace the static content provided in the
following nocloud-net seed files:
/var/lib/cloud/nocloud-net/{meta-data,vendor-data,user-data,network-config}
The intent of this commit is to set a foundation for LXD socket
communication that will allow us to build network hot-plug features
by eventually consuming LXD's websocket upgrade route 1.0/events to
react to network, meta-data and user-data config changes over time.
In the event that no custom network-config is provided, default to the
same network-config definition provided by LXD to the NoCloud
network-config seed file.
Supplemental features above NoCloud datasource:
surface all custom instance data config keys via cloud-init query ds
which aids in discoverability of features/tags/labels as well as
conditional #cloud-config jinja templates operations based on custom
config options.
TBD: better cloud-init query support for dot-delimited keys
|
|
This commit removes automatically installing udev rules for hotplug
and adds a module to install them instead.
Automatically including the udev rules and checking if hotplug was
enabled consumed too many resources in certain circumstances. Moving the
rules to a module ensures we don't spend extra extra cycles on hotplug
if hotplug functionality isn't desired.
LP: #1946003
|
|
In #919 (81299de), we refactored some of the code used to bring up
networks across distros. Previously, the call to bring up network
interfaces during 'init' stage unintentionally resulted in a no-op
such that network interfaces were NEVER brought up by cloud-init, even
if new network interfaces were found after crawling the metadata.
The code was altered to bring up these discovered network interfaces.
On ubuntu, this results in a 'netplan apply' call during 'init' stage
for any ubuntu-based distro on a datasource that has a NETWORK
dependency. On GCE, this additional 'netplan apply' conflicts with the
google-guest-agent service, resulting in an instance that can no
be connected to.
This commit adds a 'disable_network_activation' option that can be
enabled in /etc/cloud.cfg to disable the activation of network
interfaces in 'init' stage.
LP: #1938299
|
|
OpenNebula 6.1.80 (current dev. version) is introducing new IPv6 gateway
contextualization variable ETHx_IP6_GATEWAY, which mimics existing
variable ETHx_GATEWAY6. The ETHx_GATEWAY6 used until now will
be depracated in future relase (ET spring 2022).
See:
- new variable - https://github.com/OpenNebula/one/commit/e4d2cc11b9f3c6d01b53774b831f48d9d089c1cc
- deprecation tracking issue - https://github.com/OpenNebula/one/issues/5536
Also, added support for SET_HOSTNAME context variable, which is
currently widely used variable to configure guest VM hostname. See
https://docs.opennebula.io/6.0/management_and_operations/references/template.html#context-section
|
|
Cloud tests have been replaced with integration tests
|
|
|
|
Add retries to DatasourceGCE when connecting to GCE.
Sometimes when the trying to fetch the metadata,
cloud-init fails and the fallback datasource NoCloud is used which is
not expected. Add retries to ensure loading of the data source.
|
|
Remove a duplicate "a" in the docs, and change the bug reporting
documentation to tell users to run the commands with sudo.
LP: #1940236
|
|
|
|
This patch finally introduces the Cloud-Init Datasource for VMware
GuestInfo as a part of cloud-init proper. This datasource has existed
since 2018, and rapidly became the de facto datasource for developers
working with Packer, Terraform, for projects like kube-image-builder,
and the de jure datasource for Photon OS.
The major change to the datasource from its previous incarnation is
the name. Now named DatasourceVMware, this new version of the
datasource will allow multiple transport types in addition to
GuestInfo keys.
This datasource includes several unique features developed to address
real-world situations:
* Support for reading any key (metadata, userdata, vendordata) both
from the guestinfo table when running on a VM in vSphere as well as
from an environment variable when running inside of a container,
useful for rapid dev/test.
* Allows booting with DHCP while still providing full participation
in Cloud-Init instance data and Jinja queries. The netifaces library
provides the ability to inspect the network after it is online,
and the runtime network configuration is then merged into the
existing metadata and persisted to disk.
* Advertises the local_ipv4 and local_ipv6 addresses via guestinfo
as well. This is useful as Guest Tools is not always able to
identify what would be considered the local address.
The primary author and current steward of this datasource spoke at
Cloud-Init Con 2020 where there was interest in contributing this datasource
to the Cloud-Init codebase.
The datasource currently lives in its own GitHub repository at
https://github.com/vmware/cloud-init-vmware-guestinfo. Once the datasource
is merged into Cloud-Init, the old repository will be deprecated.
|
|
|
|
Currently cloud-init generates fallback network config on various
scenarios.
For example:
1. When no DS found
2. There is no 'network' info given in DS metadata.
3. If a DS gives a network config once and upon reboot if DS doesn't
give any network info, previously set network data will be
overridden.
A newly introduced key in cloud.cfg.tmpl can be used to control this
behavior on PhotonOS.
Also, if OS comes with a set of default network files(configs), like in
PhotonOS, cloud-init should not overwrite them by default.
This change also includes some nitpicking changes of reorganizing few
config variables.
Signed-off-by: Shreenidhi Shedi <sshedi@vmware.com>
|
|
|
|
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
|
|
Add a new switch allow_raw_data to control raw data feature, update
the documentation. Fix bugs about max_wait.
|
|
Update doc references to 'main' default branch due to rename.
Also some links have eroded:
- for doc links directly to a line num link to a
blob/<commit>/file/path#L10 instead of blob/<branch_name>.
- pytest.param link to a specific version doc as latest has dropped
the link
|
|
v1 network config currently has no concept of interface-specific DNS,
which is required for certain renderers. To fix this, added an
optional 'interface' key on the v1 nameserver definition. If
specified, it makes the DNS settings specific to the interface.
Otherwise, it will be defined as global DNS as it always has.
Additionally, DNS for v2 wasn't being recognized correctly. For DNS
defined on a particular interface, these settings now also go into the
global DNS settings as they were intended.
|
|
The name "DigitalOcean" doesn't have a space in it; it's a single
compound word written in Pascal case (upper camel case).
|
|
- 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.
|
|
instance-data.json redacts sensitive data for non-root users. Since user
data is consumed as root, we should be consuming the non-redacted data
instead.
LP: #1931392
|
|
LP: #1931577
|
|
|
|
Control is currently limited to boot events, though this should
allow us to more easily incorporate HOTPLUG support. Disabling
'instance-first-boot' is not supported as we apply networking config
too early in boot to have processed userdata (along with the fact
that this would be a pretty big foot-gun).
The concept of update events on datasource has been split into
supported update events and default update events. Defaults will be
used if there is no user-defined update events, but user-defined
events won't be supplied if they aren't supported.
When applying the networking config, we now check to see if the event
is supported by the datasource as well as if it is enabled.
Configuration looks like:
updates:
network:
when: ['boot']
|
|
git-grep showed a few more locations where we refer to a "user-scripts"
config module which is really cc_scripts_user module. Replace these
references with slightly different language so as not to confuse
future me when looking for "user-scripts" vs. "scripts-user"
|
|
Invoking walinuxagent from within cloud-init is no longer
supported/necessary
|
|
This PR adds in support so that cloud-init can run on instances
deployed on Vultr cloud. This was originally brought up in #628.
Co-authored-by: Eric Benner <ebenner@vultr.com>
|
|
|
|
New datasource utilizing UpCloud metadata API, including relevant unit
tests and documentation.
|
|
Add support for openstack's dynamic vendor data, which appears under openstack/latest/vendor_data2.json
This adds vendor_data2 to all pathways; it should be a no-op for non-OpenStack providers.
LP: #1841104
|
|
If cloud-init is enabled on VMware platform, cloud-init will wait until
its configuration file is ready and currently the max wait is 90
seconds by default. With our test, this configuration file should be
ready within 1 second, so change it to 15 seconds for better
performance. Also update the documentation about how to change the
default value in cloud-init configuration file.
|
|
Two shell code blocks are not marked as such, confusing rst to consider
them as yaml. Be explicit about their syntax, and use $ prompt to match
elsewhere in the docs.
/home/travis/build/canonical/cloud-init/doc/rtd/topics/format.rst:28: WARNING: Could not lex literal_block as "yaml". Highlighting skipped.
/home/travis/build/canonical/cloud-init/doc/rtd/topics/format.rst:52: WARNING: Could not lex literal_block as "yaml". Highlighting skipped.
Signed-off-by: Dan Kenigsberg <danken@redhat.com>
|
|
The company name has two distinct words.
Signed-off-by: Dan Kenigsberg <danken@redhat.com>
|
|
Added some missing IPv6 subnet configuration types
(ipv6_dhcpv6-stateful, ipv6_dhcpv6-stateless, ipv6_slaac) to Networking
config v1 documentation.
|
|
|
|
We don't currently document our passthrough behaviour, which has lead to
some user confusion about what they can rely upon on Ubuntu systems.
This clarifies our support.
|
|
Our HACKING doc is very long, making it hard to justify expanding or
restructuring its content too much. This moves the testing section to
its own doc, and adds section headers in to make finding/linking to
testing guidelines easier.
To avoid confusion, the title of debugging.rst is changed.
|
|
This commit removes lines which are invalid configuration.
|
|
Update documentation for network-config-format-v2 to reflect the fact that
routes are a per-interface property, not a global network property.
|
|
This introduces an optional, more complex OS_IMAGE format (`<image
id>::<os>::<release>`) which allows the specification of the OS/OS
release which the given image ID corresponds to. This information is
used to skip tests which do not apply to the image.
This commit is comprised of the following discrete changes:
* introduce the IntegrationImage class, to handle parsing and storing
the new OS_IMAGE format
* support inferring the OS and OS release of Ubuntu series, so that we
can continue to set OS_IMAGE to just a series name and have test
skipping work
* add documentation on Image Selection to integration_tests.rst
* introduce the actual skipping behaviour based on OS marks
* apply the `ubuntu` mark to all tests that should be skipped on
non-Ubuntu operating systems
|
|
Allow root user to validate the userdata provided to the launched
machine using `cloud-init devel schema --system`
|
|
|
|
|
|
Also update MAC addresses used in testcases to remove quotes where not
required and add single quotes where quotes are required.
|
|
* docs: Add hot to use cloud-localds to boot qemu
There is a complete lack of documentation on using cloud-localds with
cloud-init to boot an image locally.
Drive by, added some more whitepapers, blogs, and videos
* fix line length
* * add where cloud-localds comes from
* add more specific example with metadata and network config
* Add link to cloud-utils package
|
|
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.
|
|
|
|
LP: #1888858
|
|
- use `sh` as highlight language of the code block
- change order so that the confusing indentation is less confusing
|
|
* pull ssh keys from imds first and fall back to ovf if unavailable
* refactor log and diagnostic messages
* refactor the OpenSSLManager instantiation and certificate usage
* fix unit test where exception was being silenced for generate cert
* fix tests now that certificate is not always generated
* add documentation for ssh key retrieval
* add ability to check if http client has security enabled
* refactor certificate logic to GoalState
|
|
|
