These lines forced systemd-networkd to wait until `ucd` had
completed.
In turn, `ucd` requires the network to be active in order
to install packages. It waits for the network to become
active, even.
Surely, this is untenable. Ucd will have to accept any
network state and may not prevent it from starting as
early as possible, which would be counter to any fast
boot initiative.
Instead of keep duplicating existing code, we can make this program
a little bit more versatile and cover all 3 use cases and add some
extensibility for further additions.
A static table describes what needs fetching and from where. The
rest is logically the same and so the delta isn't so bad.
We add tencent cloud support on top of this.
The ucd-aws program fetches the user-data for an AMI instance
over http from 169.254.169.254, and passes it back to ucd.
The service is not supposed to be enabled unless you are running
on AWS, as it is highly specific to that cloud.
cloud-init-pre-network:
runs before network service.
this service gets metadata from local datasources
in order to configure network stuff before network service
and configures the instance on its first booot
cloud-init:
runs after network service and will get userdata/metadata
from datasources(local/network). This service fixes disk
and filesystem
add first-boot-setup and no-network options
update documentation
cloud-init-firstboot service will do initial tasks
* create and set up default user
* get and process metadata/userdata from datasources
* disable root login
this service will run once (firstboot)
cloud-init service won't run at the first boot
but it will do at next boot times
* verify/fix/resize/grow up partitions and filesystems
* get and process userdata from datasources (TODO: optional)
Brett T. Warden