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.

Sign up for GitHub

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

Jump to bottom

netavark, dns: don't double-fork aardvark instead wait for the aardvark process to return. #308

Merged
merged 1 commit into from
Jul 15, 2022
Merged

netavark, dns: don't double-fork aardvark instead wait for the aardvark process to return. #308

merged 1 commit into from
Jul 15, 2022

Conversation

flouthoc
Copy link
Collaborator

@flouthoc flouthoc commented Jun 15, 2022 •
edited
Loading

Netavark now does not double-forks aardvark-dns's server instead it
waits for aardvark-process to return back and success return means
aardvark-dns is ready to serve requests and now forking happens at
aardvark end.

See: https://doc.rust-lang.org/std/process/struct.Command.html#method.spawn

This needs: containers/aardvark-dns#148

Should help in:

Alternative to: #300

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jun 15, 2022

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: flouthoc

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

@flouthoc
Copy link
Collaborator Author

@Luap99 I tried this in combination with containers/aardvark-dns#148 and setup works fine for me. Now aardvark will return from parent when everything is ready and it is actually serving DNS requests on the assigned IP addresses ( only tries for 10 times with delay of 10ms ).

Luap99
Luap99 reviewed Jun 15, 2022
View reviewed changes
src/dns/aardvark.rs Outdated Show resolved Hide resolved
@flouthoc flouthoc requested a review from Luap99 June 16, 2022 10:11
@flouthoc
Copy link
Collaborator Author

@Luap99 PTAL again but we have to wait for aardvark PR to get reviewed first.

Luap99
Luap99 reviewed Jul 12, 2022
View reviewed changes
src/dns/aardvark.rs Outdated Show resolved Hide resolved
@flouthoc
Copy link
Collaborator Author

Rebased.

@Luap99
Copy link
Member

Luap99 commented Jul 13, 2022

LGTM I think it is expected that the integration tests fail since we need the aardvark from the other PR.

@flouthoc
Copy link
Collaborator Author

Is rebase enough to get latest aardvark from main branch ? @cevich Could you help confirming this please.

@Luap99
Copy link
Member

Luap99 commented Jul 14, 2022

@flouthoc just rebase and see if it works

@flouthoc
Copy link
Collaborator Author

I don't think aardvark is updated yet, integration is stuck on check iptables driver is in use

@baude
Copy link
Member

baude commented Jul 14, 2022

@flouthoc i'll take a peek

@flouthoc
Copy link
Collaborator Author

( Just pasting here for info ) To make sure i ran tests on my local ( but my local could be different than CI) . So maybe we should confirm if aardvark is updated on CI or not.

[fl@fedora netavark]$ sudo bats test/
[sudo] password for fl: 
 ✓ netavark version
 ✓ netavark error - invalid ns path
 ✓ netavark error - invalid config path
 ✓ check iptables driver is in use
 ✓ iptables - internal network
 ✓ iptables - simple bridge
 ✓ iptables - ipv6 bridge
 ✓ iptables - dual stack dns with alt port
 ✓ iptables - check error message from netns thread
 ✓ iptables - port forwarding ipv4 - tcp
 ✓ iptables - port forwarding ipv6 - tcp
 ✓ iptables - port forwarding dualstack - tcp
 ✓ iptables - port forwarding ipv4 - udp
 ✓ iptables - port forwarding ipv6 - udp
 ✓ iptables - port forwarding dualstack - udp
 ✓ iptables - port forwarding ipv4 - sctp
 ✓ iptables - port forwarding ipv6 - sctp
 ✓ iptables - port forwarding dualstack - sctp
 ✓ iptables - port range forwarding ipv4 - tcp
 ✓ iptables - port range forwarding ipv6 - tcp
 ✓ iptables - port range forwarding ipv4 - udp
 ✓ iptables - port range forwarding ipv6 - udp
 ✓ iptables - port range forwarding dual - udp
 ✓ iptables - port range forwarding dual - tcp
 ✓ iptables - port forwarding with hostip ipv4 - tcp
 ✓ iptables - port forwarding with hostip ipv4 dual stack- tcp
 ✓ iptables - port range forwarding with hostip ipv6 - tcp
 ✓ iptables - port range forwarding with hostip ipv6 dual stack - tcp
 ✓ iptables - port range forwarding with hostip ipv4 - udp
 ✓ iptables - port range forwarding with hostip ipv6 - udp
 ✓ bridge ipam none
 ✓ bridge unknown ipam driver
 ✓ iptables - isolate networks
 ✓ iptables - test read only /proc
 - check firewalld driver is in use (skipped: TODO: Firewalld driver swapped with iptables until firewalld 1.1.0)
 ✓ firewalld - simple bridge
 ✓ firewalld - ipv6 bridge
 ✓ firewalld - dual stack dns with alt port
 ✓ firewalld - check error message from netns thread
 ✓ firewalld - port forwarding ipv4 - tcp
 ✓ firewalld - port forwarding ipv6 - tcp
 ✓ firewalld - port forwarding dualstack - tcp
 ✓ firewalld - port forwarding ipv4 - udp
 /usr/libexec/bats-core/bats-exec-test: line 116: 39038 Killed                  nsenter -n -t $HOST_NS_PID firewalld --nopid --nofork --system-config "$NETAVARK_TMPDIR" &> "$NETAVARK_TMPDIR/firewalld.log"                            44/65
 ✓ firewalld - port forwarding ipv6 - udp
 ✓ firewalld - port forwarding dualstack - udp
 /usr/libexec/bats-core/bats-exec-test: line 161: 39742 Killed                  nsenter -n -t $HOST_NS_PID firewalld --nopid --nofork --system-config "$NETAVARK_TMPDIR" &> "$NETAVARK_TMPDIR/firewalld.log"                            46/65
 ✓ firewalld - port forwarding ipv4 - sctp
 ✓ firewalld - port forwarding ipv6 - sctp
 /usr/libexec/bats-core/bats-exec-test: line 159: 40353 Killed                  nsenter -n -t $HOST_NS_PID firewalld --nopid --nofork --system-config "$NETAVARK_TMPDIR" &> "$NETAVARK_TMPDIR/firewalld.log"                            48/65
 ✓ firewalld - port forwarding dualstack - sctp
 ✓ firewalld - port range forwarding ipv4 - tcp
 /usr/libexec/bats-core/bats-exec-test: line 173: 41079 Killed                  nsenter -n -t $HOST_NS_PID firewalld --nopid --nofork --system-config "$NETAVARK_TMPDIR" &> "$NETAVARK_TMPDIR/firewalld.log"                            50/65
 ✓ firewalld - port range forwarding ipv6 - tcp
 /usr/libexec/bats-core/bats-exec-test: line 102: 41406 Killed                  nsenter -n -t $HOST_NS_PID firewalld --nopid --nofork --system-config "$NETAVARK_TMPDIR" &> "$NETAVARK_TMPDIR/firewalld.log"                            51/65
 ✓ firewalld - port range forwarding ipv4 - udp
 ✓ firewalld - port range forwarding ipv6 - udp
 ✓ firewalld - port range forwarding dual - udp
 ✓ firewalld - port range forwarding dual - tcp
 ✓ firewalld - port forwarding with hostip ipv4 - tcp
 /usr/libexec/bats-core/bats-exec-test: line 161: 43286 Killed                  nsenter -n -t $HOST_NS_PID firewalld --nopid --nofork --system-config "$NETAVARK_TMPDIR" &> "$NETAVARK_TMPDIR/firewalld.log"                            56/65
 ✓ firewalld - port forwarding with hostip ipv4 dual stack- tcp
 ✓ firewalld - port range forwarding with hostip ipv6 - tcp
 ✓ firewalld - port range forwarding with hostip ipv6 dual stack - tcp
 /usr/libexec/bats-core/bats-exec-test: line 114: 44367 Killed                  nsenter -n -t $HOST_NS_PID firewalld --nopid --nofork --system-config "$NETAVARK_TMPDIR" &> "$NETAVARK_TMPDIR/firewalld.log"                            59/65
 ✓ firewalld - port range forwarding with hostip ipv4 - udp
 ✓ firewalld - port range forwarding with hostip ipv6 - udp
 ✓ simple macvlan setup
 ✓ macvlan setup internal
 ✓ macvlan setup with mtu
 ✓ macvlan modes
 ✓ macvlan ipam none

65 tests, 0 failures, 1 skipped

@Luap99
Copy link
Member

Luap99 commented Jul 14, 2022

I am sure that aardvark is not updated, you could check with hack/get_ci_vm

@cevich
Copy link
Member

cevich commented Jul 14, 2022

I am sure that aardvark is not updated, you could check with hack/get_ci_vm

Yep. So it's suppose to come from CI runs on the 'main' branch, perhaps that is broken. You can see by going to https://cirrus-ci.com/github/containers/aardvark-dns/<branch>...Looks mostly green 😕

We do collect an aardvark-dns.info file in the zip, that should contain details about the build where the binary came from...

@cevich
Copy link
Member

cevich commented Jul 14, 2022

...oh! I'm an oaf. And my memory is failing me. It's using RPMs not the latest zip like we use to do in podman. -sigh-

@cevich
Copy link
Member

cevich commented Jul 14, 2022 •
edited
Loading

Okay, more poking. It's aardvark-dns CI I must have been thinking of. It pulls the netavark.zip binary. Here, the fedora RPMs are installed, though curiously at VM image-build time we specify --exclude=netavark --exclude=aardvark-dns --exclude=cargo --exclude=rust. So hmmmm 😕

@baude baude mentioned this pull request Jul 14, 2022
Merged
@cevich
Copy link
Member

cevich commented Jul 14, 2022

Ahhh, figured it out from the build-logs.. The packages are coming in from the dnf update -y where we don't use the exclude option. I believe my intent was to NOT have these pre-installed, since we want fresh ones at runtime (correct?). Let me think how this can be fixed w/o making you wait for me to muck around in the image build scripts...

@baude
Copy link
Member

baude commented Jul 14, 2022

already fixed in #344

@cevich
Copy link
Member

cevich commented Jul 14, 2022

Yep @baude we need that. I'll work on fixing the images as well (for the future).

@cevich cevich mentioned this pull request Jul 14, 2022
Merged
@cevich
Copy link
Member

cevich commented Jul 14, 2022

To be clear: The new images I'm building are not required in this PR. I'm just referencing it in case someone wonders how/where/why in the future.

@flouthoc flouthoc force-pushed the remove-spawn branch 2 times, most recently from 861fc7e to 4010a74 Compare July 15, 2022 14:35
@flouthoc
netavark, dns: don't double-fork aardvark instead wait for process
fb73fa2 
Netavark now does not double-forks aardvark-dns's server instead it
waits for aardvark-process to return back and success return means
aardvark-dns is ready to serve requests and now forking happens at
aardvark end.

This needs: containers/aardvark-dns#148

Signed-off-by: Aditya R <[email protected]>
@flouthoc
Copy link
Collaborator Author

aha, integration tests are green with new aardvark. @Luap99 @baude @mheon This should be good to go now.

@Luap99
Copy link
Member

Luap99 commented Jul 15, 2022

/lgtm

@openshift-ci openshift-ci bot added the lgtm label Jul 15, 2022
@openshift-ci openshift-ci bot merged commit be4b023 into containers:main Jul 15, 2022
@Luap99 Luap99 mentioned this pull request Jul 22, 2022
Closed
@flouthoc flouthoc mentioned this pull request Sep 28, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Luap99 Luap99 Luap99 left review comments

Assignees

@Luap99 Luap99

Labels
approved lgtm
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@flouthoc @Luap99 @baude @cevich