preflight-linux: Add logic to check if /etc/resolv.conf managed by systemd-resolved

[praveenkumar]

Current logic checks if systemd-resolved service is running and add the dispatcher file to network manager config which uses systemd-resolve to update the domain and dns for crc interface. But it is observed for systems which have systemd-resolved service enabled and running but the /etc/resolv.conf is not managed by it this dispatcher file is not going to use for dns resolution and user failed to start the cluster.

This PR add logic to check if /etc/resolv.conf actually managed by systemd-resolved and if not then use dnsmasq configuration which works as expected.

Fixes: Issue #4110

[praveenkumar]

/hold

This uses go-1.21 functionality to check if a item present in slice it should go after #4139 one.

[praveenkumar]

but the /etc/resolv.conf is not managed by it this dispatcher file is not going to use for dns resolution and user failed to start the cluster.

Not so sure about this, my feeling would be that the dispatcher is called when the NM interface changes state, but then the resolvectl call it contains has no effect on DNS resolution as systemd-resolved does not manage /etc/resolv.conf?

Yes dispatcher is called and even command is executed but since the /etc/resolv.conf not managed it have no effect.

[cfergeau]

but the /etc/resolv.conf is not managed by it this dispatcher file is not going to use for dns resolution and user failed to start the cluster.

Not so sure about this, my feeling would be that the dispatcher is called when the NM interface changes state, but then the resolvectl call it contains has no effect on DNS resolution as systemd-resolved does not manage /etc/resolv.conf?

Yes dispatcher is called and even command is executed but since the /etc/resolv.conf not managed it have no effect.

Can this be clarified in the commit log?

[praveenkumar]

but the /etc/resolv.conf is not managed by it this dispatcher file is not going to use for dns resolution and user failed to start the cluster.

Not so sure about this, my feeling would be that the dispatcher is called when the NM interface changes state, but then the resolvectl call it contains has no effect on DNS resolution as systemd-resolved does not manage /etc/resolv.conf?

Yes dispatcher is called and even command is executed but since the /etc/resolv.conf not managed it have no effect.

Can this be clarified in the commit log?

Updated.

[praveenkumar]

/unhold

[openshift-ci[bot]]

@praveenkumar: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/security	0e885fee669d211b3dc7f3f6c8ea7621ad3602be	link	false	/test security

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository. I understand the commands that are listed [here](https://go.k8s.io/bot-commands).

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cfergeau

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/crc-org/crc/blob/main/OWNERS)~~ [cfergeau] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment