passt: Build and publish Passt binding CNI image

[oshoval]

What this PR does / why we need it:
Include DaemonSet manifest to deploy the binary on the cluster nodes.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• Design: A design document was considered and is present (link) or not required
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
• Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
• Community: Announcement to kubevirt-dev was considered

Release note:

[oshoval]

/uncc @maiqueb @qinqon

[qinqon]

The daemonsets should be living here also a mechanism to deploy it from this repo manually. CNAO should just use those manifests.

[oshoval]

not ready for review yet, will update once it is
thanks

[oshoval]

Removed the script and adapted the dockerfile to use ADD

[oshoval]

Please look on kubevirt/cluster-network-addons-operator#1829
no need to review yet because little stuff going to be changed,
the thing that important to understand is as i answered is that a tag on this repo, will publish the 2 images

1. kubevirt_ipam_controller:tag (as was before)
2. passt_binding_cni:tag (the new one)

This way once a new tag is released on this repo, CNAO will bump both images together of this component
CNAO also deployed them together under the same flag we already have kubevirtIpamController in the CR

[oshoval]

answered / addressed comments
updated make targets

[qinqon]

/lgtm
/approve

[oshoval]

had to change something, hopefully it will fix the e2e in the building / pushing phase (need to use local registry as done for IMG)

[qinqon]

/lgtm
/approve

[oshoval]

had to rebase because otherwise it wont be merged due to github branch protection

[qinqon]

/lgtm
/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: qinqon

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 [qinqon]

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

[oshoval]

Thanks

We just need to allow pushing to ghcr.io/kubevirt/passt-binding-cni as was done for
ghcr.io/kubevirt/ipam-controller please
https://github.com/kubevirt/ipam-extensions/actions/runs/10057056570/job/27797219641

ERROR: failed to solve: failed to push ghcr.io/kubevirt/passt-binding-cni:latest: failed commit on ref "manifest-sha256:14aa2d7f981bb512c23c017ce1288683b7b983fc5b9d908f8937dbf65e870da7": unexpected status from PUT request to https://ghcr.io/v2/kubevirt/passt-binding-cni/manifests/sha256:14aa2d7f981bb512c23c017ce1288683b7b983fc5b9d908f8937dbf65e870da7: 403 Forbidden

[maiqueb]

Thanks

We just need to allow pushing to ghcr.io/kubevirt/passt-binding-cni as was done for ghcr.io/kubevirt/ipam-controller please https://github.com/kubevirt/ipam-extensions/actions/runs/10057056570/job/27797219641

ERROR: failed to solve: failed to push ghcr.io/kubevirt/passt-binding-cni:latest: failed commit on ref "manifest-sha256:14aa2d7f981bb512c23c017ce1288683b7b983fc5b9d908f8937dbf65e870da7": unexpected status from PUT request to https://ghcr.io/v2/kubevirt/passt-binding-cni/manifests/sha256:14aa2d7f981bb512c23c017ce1288683b7b983fc5b9d908f8937dbf65e870da7: 403 Forbidden

wait so you're adding another image ? didn't we want to have everything in the same image so we don't have to do anything downstream ?

[oshoval]

wait so you're adding another image ? didn't we want to have everything in the same image so we don't have to do anything downstream ?

We already have a separated downstream image for the CNI binary (Or Mergi did), so it doesnt make sense to enforce everything to be in the same image.
Downstream doesn't need to create a new image, it exists already.
Having both U/S and D/S almost the same is a better and simpler design imho.

The new U/S image is simple, it just downloads the pre compiled binary and put it in a container image.