upstart: drop vestigial support for upstart (SC-902)

[blackboxsw]

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.

Proposed Commit Message

Grab above

Additional Context

Packaging branch to also remove emit_upstart from a modified /etc/cloud/cloud.cfg across upgrade from debian/cloud-init.postinst #1429

Test Steps

Checklist:

• My code follows the process laid out in the documentation
• I have updated or added any unit tests accordingly
• I have updated or added any documentation accordingly

[blackboxsw]

Dropping this PR @TheRealFalcon was working on this ticket today. Sorry James.

[TheRealFalcon]

Looks good, but I think there's a few more:

• https://github.com/canonical/cloud-init/blob/main/cloudinit/cmd/main.py#L350-L364
• https://github.com/canonical/cloud-init/blob/main/doc/userdata.txt#L55-L60
• https://github.com/canonical/cloud-init/blob/main/doc/examples/cloud-config-archive-launch-index.txt#L26
• https://github.com/canonical/cloud-init/blob/main/doc/examples/cloud-config-archive.txt#L12 (TIL cloud-config-archive)
• https://github.com/canonical/cloud-init/blob/main/doc/examples/cloud-config.txt#L458-L467 (that whole example is invalid anyway)
• Nit, might be worth re-wordsmithing this comment as upstart isn't really a good comparison point anymore: https://github.com/canonical/cloud-init/blob/main/systemd/cloud-config.target#L1-L6

[blackboxsw]

Looks good, but I think there's a few more:

• https://github.com/canonical/cloud-init/blob/main/cloudinit/cmd/main.py#L350-L364

I had intentionally left this in thinking there could be some custom image uses of touch /var/lib/cloud/data/no-net to prevent the network datasource from being detected for images which mandate that init-local detection is valid. There is no other way for a custom image to "disable" network datasource detection which may cost them a lot of time on boot. I'm inclined to leave it in as there may be use-cases in the wild that make use of this marker file. I've changed the comment to not indicate the upstart
aspect of this behavior as that is long gone.

Removed all doc changes below and supplemented cloud-config-archive with a text/cloud-config in the example.

• https://github.com/canonical/cloud-init/blob/main/doc/userdata.txt#L55-L60
• https://github.com/canonical/cloud-init/blob/main/doc/examples/cloud-config-archive-launch-index.txt#L26
• https://github.com/canonical/cloud-init/blob/main/doc/examples/cloud-config-archive.txt#L12 (TIL cloud-config-archive)
• https://github.com/canonical/cloud-init/blob/main/doc/examples/cloud-config.txt#L458-L467 (that whole example is invalid anyway)

• Nit, might be worth re-wordsmithing this comment as upstart isn't really a good comparison point anymore: https://github.com/canonical/cloud-init/blob/main/systemd/cloud-config.target#L1-L6

Changed text of both systemd/cloud-config.target and systemd/cloud-init.target to be a bit more helpful.

[blackboxsw]

I had intentionally left this in thinking there could be some custom image uses of touch /var/lib/cloud/data/no-net to prevent the network datasource from being detected for images which mandate that init-local detection is valid.

On further reflection, I think this undocumented magic file ends up being a really big hammer that "turns off" all of init-network stage operations including any config modules that should be run in that stage in an attempt to limp along a semi-configured system that should have failed early due to network config being absent.

Given this, I can defend dropping this. The original scenario where this was instrumented (trusty/upstart) was to catch when blocking on the network configuration timedout so network was assumed as not up. Cloud-init at the time wanted to get as much of the system up as possible to ensure it was "accessible" despite the fact that desired network configuration was inoperable. I think our perspective on the project has changed in recent years as we now want cloud-init to lean toward more strict handling of instance configuration, raising errors earlier and being as conspicuous about those errors as possible to reduce hidden or overlooked misconfiguration of an instance.

[blackboxsw]

Just to double check, note as well that Google Container optimized OS is running a systemd init system and has cloud-init 21.4 as of this writing.

$ systemd-analyze
Startup finished in 1.433s (kernel) + 10.793s (userspace) = 12.227s 
multi-user.target reached after 10.776s in userspace
/usr/lib/python-exec/python3.6/cloud-init 21.4

[TheRealFalcon]

Yeet!