Add static keepalived build

[juanluisvaladas]

Description

This is part of keepalived support, which is tracked in #4181.

This is the first and easiest step to get merged, this adds keepalived to the build.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

How Has This Been Tested?

• Manual test
• Auto test added

As there are multiple steps to this process, there will be inttests added in the next two steps of keepalived.

Checklist:

• My code follows the style guidelines of this project
• My commit messages are signed-off
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have checked my code and corrected any misspellings

[twz123]

I've noticed this:

$ embedded-bins/staging/linux/bin/keepalived --version 2>&1 | head -n1
Keepalived v2.2.8 (04/04,2023), git commit v2.2.7-154-g292b299e+

Not sure if we can do something about this strange git commit. We're building from "the official" tarball, so the tarball might have been generated from the wrong commit? The diff to the actual git tag is minimal: acassen/keepalived@292b299...v2.2.8

[twz123]

Are you sure this is necessary? (Same for line 18 in the keepalived Dockerfile.)

[juanluisvaladas]

D'oh, it's not. This must have slipped through while I was doing some debugging.

[twz123]

Suggested change

	RUN apk add build-base curl \
	linux-headers \
	openssl-dev openssl-libs-static \
	libnl3-dev libnl3-static
	RUN apk add build-base curl \
	linux-headers \
	openssl-dev openssl-libs-static \
	libnl3-dev libnl3-static

(Or change all other indentation to spaces?)

[twz123]

Formatting nit

Suggested change

	RUN cd /keepalived-$VERSION && \
	CFLAGS='-static -s' LDFLAGS=-static ./configure --disable-dynamic-linking && \
	make -j$(nproc)
	RUN cd /keepalived-$VERSION \
	&& CFLAGS='-static -s' LDFLAGS=-static ./configure --disable-dynamic-linking \
	&& make -j$(nproc)

[juanluisvaladas]

I'll change it no problem.
Is this some convention I'm not aware of? I'm asking because we also have && \ in the konnectivity's and iptables' dockerfile. Maybe we should change it there as well.

[twz123]

It's the stuff my auto formatter does 👼

I'd only change that in other places when they're actually touched in some way, though.

[twz123]

Can we keep keepalived out of this list until we actually use it?

[twz123]

I've noticed this:

$ embedded-bins/staging/linux/bin/keepalived --version 2>&1 | head -n1
Keepalived v2.2.8 (04/04,2023), git commit v2.2.7-154-g292b299e+

Not sure if we can do something about this strange git commit. We're building from "the official" tarball, so the tarball might have been generated from the wrong commit? The diff to the actual git tag is minimal: acassen/keepalived@292b299...v2.2.8

BTW the Alpine package behaves the same:

$ docker run --rm alpine:3.19 sh -c 'apk add keepalived && keepalived --version 2>&1 | head -n1'
fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/community/x86_64/APKINDEX.tar.gz
(1/3) Installing keepalived-common (2.2.8-r0)
(2/3) Installing libnl3 (3.9.0-r1)
(3/3) Installing keepalived (2.2.8-r0)
Executing busybox-1.36.1-r15.trigger
OK: 9 MiB in 18 packages
Keepalived v2.2.8 (04/04,2023), git commit v2.2.7-154-g292b299e+

[juanluisvaladas]

Can we keep keepalived out of this list until we actually use it?

Hmm I could but the thing is that keepalived in posix_bins is also a test that proves that the build works, so I'm not very happy about adding the build code if we are not verifying that the build. I think I'll just close this PR and make the 2nd PR slightly larger. I'll make the 2nd PR today or tomorrow and in the meantime I'll close this one...

[twz123]

Fair enough, albeit we verified it already manually and via CI. I don't know how this could regress until the 1.30 release. Even if it would, fixing would probably be trivial and could be done when actually enabling the build.