Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from
May 7, 2024

Conversation

praveenkumar
Copy link
Member

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

@openshift-ci openshift-ci bot requested review from cfergeau and gbraad May 3, 2024 12:46
@praveenkumar
Copy link
Member Author

/hold

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

Copy link
Contributor

@cfergeau cfergeau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@praveenkumar
Copy link
Member Author

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
Copy link
Contributor

cfergeau commented May 6, 2024

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
Copy link
Member Author

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
Copy link
Member Author

/unhold

…stemd-resolved

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
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.

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.
Copy link

openshift-ci bot commented May 7, 2024

@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 0e885fe link false /test security

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Copy link

openshift-ci bot commented May 7, 2024

[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:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved label May 7, 2024
@praveenkumar praveenkumar merged commit 75b9141 into crc-org:main May 7, 2024
23 of 27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants