manifest: Include systemd-resolved for F33 change

[jdoss]

This PR adds the systemd-resolved packages into FCOS. It is going to be used by default in Fedora 33 per this change request: https://fedoraproject.org/wiki/Changes/systemd-resolved

Adding the systemd-resolved packages back in gets us ready for this change. It won't impact how DNS is configured or used and it let's users get ready for the change in Fedora 33.

[bgilbert]

What sort of "getting ready" does this change enable? I'm not sure if it makes sense to add the service but not switch over to using it. We might make that switch in advance of Fedora 33, if that makes sense, or at the same time as Fedora 33.

[jdoss]

You can switch to using systemd-resolved on Fedora Workstation right now if you want. It is a pretty easy change and I would like to start using on my FCOS deployments now to ensure I don't have any surprises later.

[cgwalters]

Minor nit: our commit messages match Linux kernel style generally and usually have a "topic prefix" and no period at the end, and if you can succinctly describe why in the subject that's great too e.g.
manifest: Include systemd-resolved for F33 change

[cgwalters]

Also I'd really like to see us get in the habit of modifying the test cases as part of commits. It's really easy, for this one something like

diff --git a/tests/kola/misc-ro b/tests/kola/misc-ro
index ab5a30e..3c58e7b 100755
--- a/tests/kola/misc-ro
+++ b/tests/kola/misc-ro
@@ -20,8 +20,11 @@ get_journal_msg_timestamp() {
         | jq -r --slurp '.[0]["__MONOTONIC_TIMESTAMP"]'
 }
 
-systemctl is-enabled logrotate.service
-ok logrotate
+for unit in logrotate systemd-resolved; do
+    if ! systemctl is-enabled ${unit}; then
+        fatal "Unit ${unit} should be enabled"
+    fi
+done
 
 # https://github.com/coreos/fedora-coreos-config/commit/2a5c2abc796ac645d705700bf445b50d4cda8f5f
 if ip link | grep -o -e " eth[0-9]:"; then

to start.

To run the test against your change, use e.g.
cosa build && kola run '*'misc-ro
(Plus optionally the other tests too of course but that will also happen as part of a PR)

[cgwalters]

Another thing on this topic - as extensively discussed on the list, this is a fairly profound change to the default network stack that is almost certainly going to have fallout. Now, it should be as easy as providing an ignition config to disable the unit, but we probably also want to be sanity testing that.

[cgwalters]

Example fallout: I bet this will break this code.

[jdoss]

@cgwalters Updated my PR with your suggestions. I don't have cosa or kola setup on my workstation. Aside from RTFM on those repos do you have any tips or documentation for getting this going easily for new contributors?

[cgwalters]

And indeed the test failed:

Aug 22 01:10:22 localhost.localdomain kola-runext-misc-ro[1190]: static
Aug 22 01:10:22 localhost.localdomain kola-runext-misc-ro[1189]: + for unit in logrotate systemd-resolved
Aug 22 01:10:22 localhost.localdomain kola-runext-misc-ro[1189]: + systemctl is-enabled systemd-resolved
Aug 22 01:10:22 localhost.localdomain kola-runext-misc-ro[1191]: disabled
Aug 22 01:10:22 localhost.localdomain kola-runext-misc-ro[1189]: + fatal 'Unit systemd-resolved should be enabled'
Aug 22 01:10:22 localhost.localdomain kola-runext-misc-ro[1189]: + echo 'Unit systemd-resolved should be enabled'
Aug 22 01:10:22 localhost.localdomain kola-runext-misc-ro[1189]: Unit systemd-resolved should be enabled
Aug 22 01:10:22 localhost.localdomain kola-runext-misc-ro[1189]: + exit 1
Aug 22 01:10:22 localhost.localdomain systemd[1]: kola-runext.service: Main process exited, code=exited, status=1/FAILURE
Aug 22 01:10:22 localhost.localdomain systemd[1]: kola-runext.service: Failed with result 'exit-code'.

I suspect the reason is that it's not enabled in the Fedora base presets? I see https://src.fedoraproject.org/rpms/fedora-release/c/c7ef1abb1f1732a261d75a11c9d5d585f73f7069?branch=master

[dustymabe]

I need to dig in to the systemd-resolved change as part of coreos/fedora-coreos-tracker#609 anyway. Let me dig into this to understand it and come back with an informed response.

[cgwalters]

Hmm right, agree we should probably just take this on as part of the next/f33 branch. When you do that PR, maybe cherry-pick in this patch?

[travier]

I think there are two points here:

• Enabling systemd-resolved in the final root: I think we should try this in next as this is coming in Fedora 33 and that would bring all the benefits mentioned (but may trigger other bugs).
• Enabling systemd-resolved in the initramfs to keep networking behavior consistent between the two. This might require more work and I don't know if it's part of the F33 changes.

[dustymabe]

I think there are two points here:

• Enabling systemd-resolved in the final root: I think we should try this in next as this is coming in Fedora 33 and that would bring all the benefits mentioned (but may trigger other bugs).

I cherry-picked this patch into the "switch to F33" PR: #640

• Enabling systemd-resolved in the initramfs to keep networking behavior consistent between the two. This might require more work and I don't know if it's part of the F33 changes.

I'm not sure about that. We might need to check with the change owner. Though I imagine the initramfs doesn't matter too much as long as there is some basic DNS to grab a few files and then get to the real root.

[dustymabe]

jlebon convinced me to apply most of my f33 changes to f32 but make them conditional (that way config bot can keep syncing between the two and we don't have to eventually do a large merge back from next-devel into testing-devel). I propose we merge this into testing-devel and then #646 to make the test conditional on the fedora major version.

[dustymabe]

Just for clarity.. systemd-resolved is disabled by default in F32 and enabled by default in F33. We're not changing that with this PR, just now including the bits.

[dustymabe]

LGTM

[dustymabe]

The CI for this will fail (fixed by the commit in #646). If CI passes for #646 I'll merge this and that.

[dustymabe]

This commit was included in #646. Thanks @jdoss. I was going to merge this one individually but was convinced otherwise to prevent webhooks from going out and doing pipeline builds for state that we knew would fail tests.