Entrypoint: Produce static binary for entry

[darkmuggle]

This allows for entrypoint to be portable and cleans-up some cruft.

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: darkmuggle

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:

• OWNERS [darkmuggle]

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

[darkmuggle]

Follow-on PR to @mike-nguyen 's comment in #1824 about .PHYON.

[cgwalters]

I don't understand why it needs to be portable?

[darkmuggle]

I don't understand why it needs to be portable?

Testing. The next PR coming allows for Entry to become a CI runner from a COSA container. If you compile entry on F33, it will not work on F32 due to a libc difference. Portable makes it much easier for testing.

[cgwalters]

If you compile entry on F33, it will not work on F32 due to a libc difference.

Right but that implies we're "breaking" containerization.

Portable makes it much easier for testing.

Is this something like doing a make from your workstation and then copying the binary into a running container? Any reason why not instead to do a podman build - that's the standard container flow, and the more we make our workflow like that, the more it resembles how people build containerized applications too.

We already have a Dockerfile.dev that just layers on top of the existing cosa.

We ran into a really horrible bug in the OpenShift cluster network operator which was copying a fully statically linked binary from a container out to the host - trying to use FIPS completely broke it because it dynamically links openssl. Upstream glibc nearly doesn't support static linking. It will break things like the systemd nss plugin, etc. This led to coreos/fedora-coreos-tracker#354

Ultimately I would say this is still your call - I'm not trying to block this PR but I also think it's really important that we have a shared understanding of architecture/tooling - things like copying binaries versus containers is one of those.

[darkmuggle]

Is this something like doing a make from your workstation and then copying the binary into a running container? Any reason why not instead to do a podman build - that's the standard container flow, and the more we make our workflow like that, the more it resembles how people build containerized applications too.

Yes, this is pure developer-driven PR to reduce friction. COSA is huge, and right now, entrypoint uses in-cluster credentials for creating pods. By having a static build, it's a faster build. Although I suppose I could just make in a COSA container.

Ultimately I would say this is still your call - I'm not trying to block this PR but I also think it's really important that we have a shared understanding of architecture/tooling - things like copying binaries versus containers is one of those.

Agreed. And TBH, I would really bristle if were distributing a straight-up binary and doing a binary copy game. I think I would like to land this for the developer story. The production and consumer stories should remain container-based.

Once entry stabilizes, this can be something that's revisited.

[darkmuggle]

Actually, I'm rolling with @cgwalters objection -- it sounds, reasonable, and codifying my developer pain-point (identified above) in the code is a bit short-sighted.