This makes it easier to for example set `datasource_list = [ "Vultr" ];`
so that cloud-init doesn't scan trough all of the datasources when you
know on which target the system is going to be deployed.
Previously, one had to copy-paste the default config and adapt it.
* cloud-init: 22.4 -> 23.1.1
* cloud-init: add udhcpc support
Cloud-init use as dhcp client, dhclient, which is coming from the unmaintained package, isc-dhcp-client (refer https://www.isc.org/dhcp/) which ended support in 2022. dhclient is deprecated in nixos
Add patch to use `udhcpc` dhcp client coming from busybox instead.
PR based on #226173
refs #215571
upstream PR: https://github.com/canonical/cloud-init/pull/2125
- Fix hostname configuration on proxmox, which uses "hostname" in user-data
instead of "local-hostname" in meta-data.
- Allow setting resolv.conf through cloud-init
- Add tests for new changes
- Add timeouts to make tests fail faster
the conversion procedure is simple:
- find all things that look like options, ie calls to either `mkOption`
or `lib.mkOption` that take an attrset. remember the attrset as the
option
- for all options, find a `description` attribute who's value is not a
call to `mdDoc` or `lib.mdDoc`
- textually convert the entire value of the attribute to MD with a few
simple regexes (the set from mdize-module.sh)
- if the change produced a change in the manual output, discard
- if the change kept the manual unchanged, add some text to the
description to make sure we've actually found an option. if the
manual changes this time, keep the converted description
this procedure converts 80% of nixos options to markdown. around 2000
options remain to be inspected, but most of those fail the "does not
change the manual output check": currently the MD conversion process
does not faithfully convert docbook tags like <code> and <package>, so
any option using such tags will not be converted at all.
Since https://github.com/NixOS/nixpkgs/pull/61321, local-fs.target is
part of sysinit.target again, meaning units without
DefaultDependencies=no will automatically depend on it, and the manual
set dependencies can be dropped.
Some modules of cloud-init can cope with a network not immediately
available (notably, the EC2 module), but some others won't retry if
network is not available (notably, the Cloudstack module).
network.target doesn't give much guarantee about the network
availability. Applications not able to start without a fully
configured network should be ordered after network-online.target.
Also see #44573 and #44524.
