Bug#1025618: cloud-init and firewalld systemd unit files have ordering cycles

[Ross Vandegrift <rvandegrift@debian.org>]

On Fri, Dec 16, 2022 at 03:48:00PM -0800, Ross Vandegrift wrote:
> At a high level the issue is: firewalld.service forces network-pre.target after
> sysinit.target, but cloud-init.service forces the other way around.  In detail,
> using < to represent Before, the imposed orderings look like:
> 
> - from firewalld:
>   sysinit.target < dbus.service < firewalld.service < network-pre.target
> - from cloud-init:
>   cloud-init-local.service < network-pre.target < systemd-networkd-wait-online.service < cloud-init.service < sysinit.target
> 
> There's a few approaches to resolving this.  As far as I can tell, the only
> immediately viable one (at the bottom) requires users to manually fix this
> and accept some trade-offs.  Anyone have any better ideas?

We discussed this issue on the recent cloud-team meeting and had some
revised options.

> Modify firewalld to run before sysinit.target 
> ---------------------------------------------
[snip]

This one still seems impossible.

> Modify cloud-init to run after sysinit.target
> ---------------------------------------------
[snip]

The main downside of this one, is that cloud-init will be running too
late to configure block devices.  But this feature didn't always work
well.  So maybe we'd affect a non-working feature.

I've confirmed that cloud-init's block device setup is working well on
AWS at least.  So I think this will break working cloud-init features.
IMO, that means it is not viable.

> Locally override firewalld.service's order
> ------------------------------------------
[snip]

This remains unattractive since unsuspecting users will be left with
broken images and no clear path to fix the problem.


Modify dbus to run later
------------------------

We discussed a way improve things by shuffling dbus later, but I didn't
take good enough notes, and I can't reconstruct the details.  Sorry for
forgetting - Bastian do you recall the details?


Add Breaks or Conflicts to prevent coinstallation
-------------------------------------------------

None of the alternatives seem reasonable and installing cloud-init and
firewalld cannot produce a working Debian image.  So we should prevent
this state.

We thought Conflicts might be required because once both are unpacked,
the problematic cycle technically exists.  Though it may not cause harm
unless both services are (re-)started simultaneously.

Ross