Remove linux-headers apk from Dockerfile (upstream backport to release-4.15)

[thom311]

Backport commit fc002af to release-4.15 branch. This is upstream k8snetworkplumbingwg/ib-sriov-cni#84

Otherwise, build fails:

$ podman build -t foo -f Dockerfile
[1/2] STEP 1/7: FROM golang:1.20-alpine AS builder
[1/2] STEP 2/7: COPY . /usr/src/ib-sriov-cni
--> a78ca05e4982
[1/2] STEP 3/7: ENV HTTP_PROXY $http_proxy
--> a75387849f14
[1/2] STEP 4/7: ENV HTTPS_PROXY $https_proxy
--> 9c3cddc0ab98
[1/2] STEP 5/7: RUN apk add --no-cache --virtual build-dependencies build-base=~0.5 linux-headers=~6.3
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
ERROR: unable to select packages:
  linux-headers-6.5-r0:
    breaks: build-dependencies-20240613.095259[linux-headers~6.3]
  build-dependencies-20240613.095259:
    masked in: cache
    satisfies: world[build-dependencies=20240613.095259]
Error: building at STEP "RUN apk add --no-cache --virtual build-dependencies build-base=~0.5 linux-headers=~6.3": while running runtime: exit status 2

[openshift-ci]

Hi @thom311. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[wizhaoredhat]

/approve

[SchSeba]

/hold

Hi @thom311,
Thanks for the PR but we don't need this for the openshift images as we don't use the u/s Dockerfile
this is the Dockerfile we use https://github.com/openshift/ib-sriov-cni/blob/master/Dockerfile.rhel7 to build d/s images

let me know if we can close this PR or I miss something

[thom311]

Dockerfile.rhel7 uses a build image that requires authorization. It was also indicated, that (due to that) it's not permissible to build a container using Dockerfile.rhel7 and publish it for others (e.g. on a public quay repostiroy).

I personally, I can build images using "Dockerfile.rhel7" just fine, because I have an account. The problem is, that I am no conveniently able to share that built, as I would need to prevent unautorized users from getting it.

That means, there is no reasonable way to build an upstream image of ib-sriov-cni. It would require to patch the Dockerfile or write your own.

[SchSeba]

/ok-to-test
/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: SchSeba, thom311, wizhaoredhat

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

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

[openshift-ci]

@thom311: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[SchSeba]

/hold cancel
/label backport-risk-assessed

[SchSeba]

@thom311 you will need to create a Bug for this PR to go in I think

[thom311]

@SchSeba I am reconsidering this.

With sriov-cni, when building a container using the upstream Dockerfile, the build succeeds, but the container doesn't work (in Openshift).

What I really want to do, is being able to build latest master and release-4.x branches, and push them to a public quay.io. I personally can build, since I have credential to access registry.ci.openshift.org. But then I don't think I am allowed to publish the build result.

This makes development and testing cumbersome. And not being able share the build freely is also against open source principles.

What would be a better solution?

[SchSeba]

Hi @thom311,
I agree with you. but that is the policy right now from the company :(

so I am fine merging this one here if you want and you can push to your quay (it's private by default) and just add your user or a robot account to your cluster

[thom311]

the problem is that those upstream Dockerfile don't seem to work with the openshift forks. So while this patch fixes an obvious build-issue and makes the build succeed, it does possibly not result in anything useful (at least, it does not do that in general for the openshift/sriov repositories, in particular sriov-cni does not work).

That makes this PR pointless, I will close it. Thanks.

Optimally, we would have Dockerfiles that allow to build the opensource project and get something usable.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale