comments

doc/module-docs/cc_install_hotplug/data.yaml

@@ -1,7 +1,7 @@
 cc_install_hotplug:
   description: |
     This module will install the udev rules to enable hotplug if supported by
-    the datasource and enabled in the userdata. The udev rules will be
+    the datasource and enabled in the user-data. The udev rules will be
     installed as ``/etc/udev/rules.d/90-cloud-init-hook-hotplug.rules``.
 
     When hotplug is enabled, newly added network devices will be added to the

doc/rtd/development/summit/2017_summit.rst

@@ -42,7 +42,7 @@ that they gave as a part of the summit:
   merge request CI process and encouraged this as a way for other OSes to
   participate.
 * **Using lxd for Rapid Development and Testing**: Scott demoed setting
-  userdata when launching a lxd instance and how this can be used in the
+  user-data when launching a lxd instance and how this can be used in the
   development process. He also discussed lxd image remotes and types of images.
 
 Breakout Sessions

doc/rtd/development/summit/2023_summit.rst

@@ -85,8 +85,8 @@ Presentation takeaways
   spelunking".
 
   This aligns well with Brett’s ongoing roadmap work to raise warnings from the
-  CLI and some of the strict JSON schema validation on network-config and user
-  data/vendor-data.
+  CLI and some of the strict JSON schema validation on network-config and
+  user-data/vendor-data.
 
 * Good lessons from both AlpineLinux (Dermot Bradley), who investigated SSH
   alternatives like dropbearSSH and tinySSH, and FreeBSD (Mina Galić), who

doc/rtd/development/testing.rst

@@ -51,28 +51,14 @@ Test layout
 * ``pytest`` tests should use bare ``assert`` statements, to take advantage
   of ``pytest``'s `assertion introspection`_.
 
-``pytest`` version "gotchas"
-----------------------------
-
-As we still support Ubuntu 18.04 (Bionic Beaver), we can only use ``pytest``
-features that are available in v3.3.2. This is an inexhaustive list of
-ways in which this may catch you out:
-
-  * Only the following built-in fixtures are available [#fixture-list]_:
-
-    * ``cache``
-    * ``capfd``
-    * ``capfdbinary``
-    * ``caplog``
-    * ``capsys``
-    * ``capsysbinary``
-    * ``doctest_namespace``
-    * ``monkeypatch``
-    * ``pytestconfig``
-    * ``record_xml_property``
-    * ``recwarn``
-    * ``tmpdir_factory``
-    * ``tmpdir``
+Dependency versions
+-------------------
+
+Cloud-init supports a range of versions for each of its test dependencies, as
+well as runtime dependencies. If you are unsure whether a specific feature is
+supported for a particular dependency, check the ``lowest-supported``
+environment in ``tox.ini``. This can be ran using ``tox -e lowest-supported``.
+This runs as a Github Actions job when a pull request is submitted or updated.
 
 Mocking and assertions
 ----------------------
@@ -139,13 +125,6 @@ Test argument ordering
   * ``pytest.mark.parametrize``
   * ``mock.patch``
 
-.. [#fixture-list] This list of fixtures (with markup) can be
-   reproduced by running::
-
-     python3 -m pytest  --fixtures -q | grep "^[^ -]" | grep -v 'no tests ran in' | sort | sed 's/ \[session scope\]//g;s/.*/* ``\0``/g'
-
-   in an ubuntu lxd container with python3-pytest installed.
-
 .. LINKS:
 .. _pytest: https://docs.pytest.org/
 .. _pytest fixtures: https://docs.pytest.org/en/latest/fixture.html

doc/rtd/explanation/configuration.rst

@@ -37,7 +37,7 @@ configuration are defined in the
 Vendor-data and user-data
 =========================
 
-Added to the base configuration are :ref:`vendor-data<vendordata>` and
+Added to the base configuration are :ref:`vendor-data<vendor-data>` and
 :ref:`user-data<user_data_formats>` which are both provided by the datasource.
 
 These get fetched from the datasource and are defined at instance launch.

doc/rtd/explanation/format.rst

@@ -270,7 +270,7 @@ and a shell script (:file:`script.sh`)
 
 .. code-block:: shell-session
 
-    $ cloud-init devel make-mime -a config.yaml:cloud-config -a script.sh:x-shellscript > userdata
+    $ cloud-init devel make-mime -a config.yaml:cloud-config -a script.sh:x-shellscript > user-data.mime
 
 Create user-data containing 3 shell scripts:
 

doc/rtd/explanation/instancedata.rst

@@ -215,8 +215,8 @@ included in the ``sensitive-keys`` list which is only readable by root.
 ^^^^^^
 
 Datasource-specific data crawled for the specific cloud platform. It should
-closely represent the structure of the cloud data crawled. The structure of
-content and details provided are entirely cloud-dependent. Mileage will vary
+closely represent the structure of the data crawled. The structure of content
+and details provided are entirely cloud-dependent. Mileage will vary
 depending on what the cloud exposes. The content exposed under the ``ds`` key
 is currently **experimental** and expected to change slightly in the upcoming
 ``cloud-init`` release.

doc/rtd/explanation/vendordata.rst

@@ -1,4 +1,4 @@
-.. _vendordata:
+.. _vendor-data:
 
 Vendor-data
 ***********
@@ -31,8 +31,8 @@ Input formats
 ``Cloud-init`` will download and cache to filesystem any vendor-data that it
 finds. Vendor-data is handled exactly like
 :ref:`user-data<user_data_formats>`. This means that the vendor can supply
-multi-part input and have those parts acted on in the same way as with user
-data.
+multi-part input and have those parts acted on in the same way as with
+user-data.
 
 The only differences are:
 

doc/rtd/reference/datasources/openstack.rst

@@ -115,9 +115,9 @@ upgrade packages and install ``htop`` on all instances:
 
 For more general information about how ``cloud-init`` handles vendor-data,
 including how it can be disabled by users on instances, see our
-:ref:`explanation topic<vendordata>`.
+:ref:`explanation topic<vendor-data>`.
 
-OpenStack can also be configured to provide "dynamic vendordata"
+OpenStack can also be configured to provide "dynamic vendor-data"
 which is provided by the DynamicJSON provider and appears under a
 different IMDS path, :file:`/vendor_data2.json`.
 

doc/rtd/reference/datasources/vmware.rst

@@ -346,7 +346,7 @@ this datasource using the GuestInfo keys transport:
                name: ens*
              dhcp4: yes
 
-#. Create the userdata file :file:`userdata.yaml`\:
+#. Create the user-data file :file:`user-data.yaml`\:
 
    .. code-block:: yaml
 
@@ -405,7 +405,7 @@ this datasource using the GuestInfo keys transport:
    .. code-block:: shell
 
       export METADATA=$(gzip -c9 <meta-data.yaml | { base64 -w0 2>/dev/null || base64; }) \
-           USERDATA=$(gzip -c9 <userdata.yaml | { base64 -w0 2>/dev/null || base64; })
+           USERDATA=$(gzip -c9 <user-data.yaml | { base64 -w0 2>/dev/null || base64; })
 
 #. Assign the meta-data and user-data to the VM:
 

doc/rtd/reference/network-config-format-v2.rst

@@ -65,8 +65,8 @@ currently being defined.
 There are two physically/structurally different classes of device definitions,
 and the ID field has a different interpretation for each:
 
-Physical devices (e.g., ethernet, wifi)
----------------------------------------
+Physical devices (e.g., ethernet, Wi-Fi)
+----------------------------------------
 
 These can dynamically come and go between reboots and even during runtime
 (hotplugging). In the generic case, they can be selected by ``match:``

doc/rtd/reference/yaml_examples/scripts.rst

@@ -3,7 +3,7 @@
 Control vendor-data use
 ***********************
 
-The use of :ref:`vendor-data <vendordata>` can be controlled by the user.
+The use of :ref:`vendor-data <vendor-data>` can be controlled by the user.
 Vendor-data can be used (or disabled) with an optional prefix.
 
 For a full list of keys, refer to the

doc/rtd/spelling_word_list.txt

@@ -8,18 +8,13 @@ apport
 ar
 arg
 args
-artifacts
 authkeys
 autoinstaller
 autospecced
-available
 aways
 aws
-backend
-backends
 baseurl
 bigstep
-boolean
 bootcmd
 boothook
 boothooks
@@ -30,15 +25,13 @@ cd
 centos
 chown
 chrony
-cleanup
 cloud-init
 cloudlinux
 cloudplatform
 conf
 config
 configdrive
 configs
-copy-button
 cpu
 csr
 datasource
@@ -69,8 +62,6 @@ dss
 eal
 ec
 ecdsa
-ed
-edwardo
 errored
 es
 esm
@@ -80,24 +71,19 @@ ethernet
 eurolinux
 execve
 exoscale
-fabio
 faillog
 fips
 firstboot
 flexibile
 fqdn
 freebsd
 freenode
-fs-freq
 fstab
-galic
 gce
-gotchas
 gpart
 growpart
 gz
 hacktoberfest
-hetzner
 hostname
 hpc
 ids
@@ -164,8 +150,6 @@ pem
 pid
 pipelining
 pki
-playbook
-plugins
 postinstall
 poweroff
 ppc
@@ -187,7 +171,6 @@ rbx
 rc
 rd
 readinessprobes
-redhat
 regex
 repodata
 resizefs
@@ -213,7 +196,6 @@ smtp
 snapd
 softlayer
 somedir
-spelunking
 sr
 sshd
 ssk
@@ -231,46 +213,36 @@ syslogd
 systemd
 tcp
 teardown
-th
 timeframe
 timesyncd
-timezone
 tinyssh
 tlb
 tmp
 tmpfiles
 tracebacks
-transactional
 ua
 ubuntu
 udev
 udp
 un
 url
 urls
-userdata
 userspace
 usr
 util
-validator
 var
 vcloud
 ve
-vendordata
 veth
 vfstype
 virtuozzo
 vm
 vpc
 vsphere
 vultr
-walkthrough
 webserver
 wg
 wgx
-whitepapers
-whitespace
-wifi
 wireguard
 xor
 yakkety

doc/rtd/tutorial/qemu.rst

@@ -77,7 +77,7 @@ configure the virtual machine instance. There are three major types:
 
 * :ref:`user-data <user_data_formats>` is provided by the user, and cloud-init
   recognizes many different formats.
-* :ref:`vendor-data <vendordata>` is provided by the cloud provider.
+* :ref:`vendor-data <vendor-data>` is provided by the cloud provider.
 * :ref:`meta-data <instance-data>` contains the platform data, including
   things like machine ID, hostname, etc.