fix parsing resolv.conf when systemd-resolved is running on the host

[zhangzujian]

Pull Request

• Make sure you have followed Kube-OVN Code Style.

What type of this PR

Examples of user facing changes:

• Features
• Bug fixes
• Docs
• Tests

Which issue(s) this PR fixes

E0703 06:36:54.585261   12600 exporter_metric.go:63] failed to get /etc/resolv.conf content: open /run/systemd/resolve/resolv.conf: no such file or directory

When /etc/resolv.conf contains 127.0.0.53 as the only nameserver, then it is assumed systemd-resolved manages DNS. Because inside the container 127.0.0.53 is not a valid DNS server, Path() returns /run/systemd/resolve/resolv.conf which is the resolv.conf that systemd-resolved generates and manages.

[gemini-code-assist]

Summary of Changes

Hello @zhangzujian, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a critical issue preventing the application from correctly reading /etc/resolv.conf when systemd-resolved is active on the host, which was causing errors in DNS search metric collection. The changes ensure the correct configuration file is always targeted and refine the domain filtering logic for these metrics.

Highlights

• DNS Resolution Fix: I've addressed a bug where the application failed to correctly parse /etc/resolv.conf on hosts running systemd-resolved. Previously, resolvconf.Get() could incorrectly resolve to /run/systemd/resolve/resolv.conf within a container, leading to a 'no such file or directory' error. This change explicitly tells the resolver to read /etc/resolv.conf directly, ensuring proper DNS search metric collection.
• DNS Search Metric Logic Refinement: I've updated the logic for filtering domains when collecting DNS search metrics. Instead of ignoring domains containing 'local', the system now specifically ignores the root domain . (dot), which is a more precise and correct way to handle such entries in the search list.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request fixes two bugs in the DNS search domain metric collection. First, it changes how resolv.conf is read to avoid errors on systems using systemd-resolved. Second, it corrects the logic for filtering search domains. The changes are correct and improve the robustness of the metric collection. I've added one comment suggesting a further improvement to handle the metric lifecycle correctly, to avoid stale metrics when search domains are removed.

[coveralls]

Pull Request Test Coverage Report for Build 16043382967

Details

• 0 of 3 (0.0%) changed or added relevant lines in 1 file are covered.
• 3 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.001%) to 21.561%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pkg/daemon/exporter_metric.go	0	3	0.0%

Files with Coverage Reduction	New Missed Lines	%
pkg/daemon/exporter_metric.go	1	0.0%
pkg/ovs/ovn-nb-bfd.go	2	61.61%

Totals
Change from base Build 16042760474:	-0.001%
Covered Lines:	10512
Relevant Lines:	48754

---

💛 - Coveralls