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

WIP: Add conntrack to gcp route script #2421

Closed
wants to merge 1 commit into from
Closed

WIP: Add conntrack to gcp route script #2421

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions templates/master/00-master/gcp/files/opt-libexec-openshift-gcp-routes-sh.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -93,6 +93,11 @@ contents:
ensure_rule nat "${CHAIN_NAME}-local" --dst "${vip}" -j REDIRECT
fi
done
sleep 5
for vip in "${!vips[@]}"; do
echo "Removing stale conntrack connections for ${vip}"
conntrack -D -r "${vip}" || echo "unable to run conntrack"
Copy link
Member

Choose a reason for hiding this comment

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

It looks like /usr/sbin/conntrack is actually part the same package conntrack-tools which includes a whole daemon conntrackd.service that...I don't think we would use in OpenShift.

One option is to change the Dockerfile here to do yum -y install conntrack-tools and teach this script to exec back into the MCD container to run this.

This all relates to the larger goal of having more of these scripts migrate to Go code that's part of the MCD instead of injected onto the host. We have systemd-run as a way for the pod to schedule code on the host, we could invent e.g. /run/bin/machine-config-daemon exec conntrack -D -r "${vip"} which would use a local socket to exec code in the MCD pod.

Copy link
Member

Choose a reason for hiding this comment

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

Another alternative is to yum -y install conntrack-tools in here, and then change the pod startup to copy the binary out to the host.

Another alternative is to make it a hidden extension we only install where needed.

Or finally, we could just ship it in CoreOS but then it quickly becomes an "API" that we have to maintain ~forever and makes it hard to keep track of who's using it and what version they need etc.

Copy link
Member

Choose a reason for hiding this comment

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

(Or yet another option is to have the MCD use the netlink API to do that directly, but I wouldn't willingly inflict programming netlink API on anyone I like 😉 )

Copy link
Member

Choose a reason for hiding this comment

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

Or finally, we could say this whole problem domain should move to the apiserver operator/team and they have a daemonset that runs on the control plane 😄

Copy link
Member

Choose a reason for hiding this comment

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

For now, a PR to add to the host: openshift/os#502

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm a fan of 'do whatever is easiest' in this case. It appears that today, installing conntrack-tools is easiest. If this is seen as a negative, we should make a better option the 'easiest' option.

done
}

clear_rules() {
Expand Down