add s390x support for kubevirt builder.

[vamsikrishna-siddu]

What this PR does / why we need it:
This pr adds the s390x support to kubevirt builder image.
The kubevirt builder image for s390x does not contain Bazel. We are not including the Bazel because at the moment there is no upstream official support of Bazel for s390x. We are working with Bazel community to get the support. But it will take lot of time to get the support as the Bazel community has other priorities and they are not willing to add the support now. We also thought to publish the natively compiled Bazel Binary for s390x, We were not able to do it because of legal issues. We will include the Bazel in the kubevirt builder once we get the Bazel support on s390x.
How we are proceeding for unit and E2E Tests.
Unit Test:
We will run the unit-tests using Golang . We will publish the kubevirt builder image without Bazel to the public and use that image to run the unit tests using make go-test.

E2E Test:
We will use our own kubevirt builder image (which contains Bazel) from our internal registry, and we will override the used image using environment variable to run the e2e tests.

cc: @brianmcarey

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:

add s390x support for kubevirt builder

[kubevirt-bot]

Hi @vamsikrishna-siddu. Thanks for your PR.

I'm waiting for a kubevirt 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/test-infra repository.

[fabiand]

Howdy.

Please include an OWNERS file to specify who is owning s390 support.

Setting a

/hold

until the file is added.

For example: Add a new member to OWNERS in #11046 with a comment that they/she/he is covering for s390.

@dhiller @brianmcarey can help to do this modification

[brianmcarey]

Howdy.

Please include an OWNERS file to specify who is owning s390 support.

Setting a

/hold

until the file is added.

For example: Add a new member to OWNERS in #11046 with a comment that they/she/he is covering for s390.

I think this is something we will have to do retroactively as these are some of the first s390x contributions - the contributors are not yet members of the kubevirt org and can't be added to any special interest groups as a result.

What do you think?

@dhiller @brianmcarey can help to do this modification

[vamsikrishna-siddu]

Hello @brianmcarey @alicefr As the Bazel support is not present for s390x. We have the below proposal for enabling the kubevirt on s390x. We want to know from your side whether we can go ahead with this proposal?

Unit Test
We will run the unit-tests using Golang until we get the Bazel support on s390x. We will publish the kubevirt builder image without Bazel to the public and use that image to run the unit tests using make go-test.

E2E Test
At present we can't publish Bazel binary for s390x. We will use our own kubevirt builder image (which contains Bazel) from our internal registry, and we will override the used image using environment variable to run the e2e tests.

[brianmcarey]

Hello @brianmcarey @alicefr As the Bazel support is not present for s390x. We have the below proposal for enabling the kubevirt on s390x. We want to know from your side whether we can go ahead with this proposal?

Hi @vamsikrishna-siddu

Unit Test We will run the unit-tests using Golang until we get the Bazel support on s390x. We will publish the kubevirt builder image without Bazel to the public and use that image to run the unit tests using make go-test.

E2E Test At present we can't publish Bazel binary for s390x. We will use our own kubevirt builder image (which contains Bazel) from our internal registry, and we will override the used image using environment variable to run the e2e tests.

Would you be able to publish this builder image to quay.io ? In this case we could just use this image for both the unit test and e2e tests - this would satisfy CI. It would have to be documented that contributors wishing to build or test against s390x would have to use this builder image.

@dhiller @xpivarc - what do you think of this ?

[brianmcarey]

Actually looking at the commits again - there is further more tidying up required - the changes in this PR could be handled in a single commit.

For instance - the following commits are no longer relevant:

• 1963505
• 947bf6b

/lgtm cancel

[vamsikrishna-siddu]

Actually looking at the commits again - there is further more tidying up required - the changes in this PR could be handled in a single commit.

For instance - the following commits are no longer relevant:

• 1963505
• 947bf6b

/lgtm cancel

Hi @brianmcarey I put all the changes into a single commit and updated the PR. Please review it again. Thanks

[brianmcarey]

Thanks @vamsikrishna-siddu - just one small nit left and then should be good.

[brianmcarey]

/lgtm

thanks @vamsikrishna-siddu

[dhiller]

Howdy.

Please include an OWNERS file to specify who is owning s390 support.

Setting a

/hold

until the file is added.

For example: Add a new member to OWNERS in #11046 with a comment that they/she/he is covering for s390.

@dhiller @brianmcarey can help to do this modification

@vamsikrishna-siddu the requested change wrt ownership is still missing. I know that this is currently not possible since you are not (yet) a member of the org, but someone in sig-buildsystem needs to own this.

So I would suggest you apply for KubeVirt membership (see here how to do this), and then we can add you to the org.

I believe we should make an exception for this case wrt/ contributions, and I think this is fair, since addition of a new build architecture is significant enough.

WDYT @fabiand @vladikr @davidvossel ?

[dhiller]

Also WDYT @aburdenthehand ?

[dhiller]

Howdy.
Please include an OWNERS file to specify who is owning s390 support.
Setting a
/hold
until the file is added.
For example: Add a new member to OWNERS in #11046 with a comment that they/she/he is covering for s390.
@dhiller @brianmcarey can help to do this modification

@vamsikrishna-siddu the requested change wrt ownership is still missing. I know that this is currently not possible since you are not (yet) a member of the org, but someone in sig-buildsystem needs to own this.

So I would suggest you apply for KubeVirt membership (see here how to do this), and then we can add you to the org.

I believe we should make an exception for this case wrt/ contributions, and I think this is fair, since addition of a new build architecture is significant enough.

WDYT @fabiand @vladikr @davidvossel ?

WRT sponsorship you can add @dhiller since I'm happy to sponsor it . maybe @brianmcarey also, I guess?

[vamsikrishna-siddu]

Howdy.
Please include an OWNERS file to specify who is owning s390 support.
Setting a
/hold
until the file is added.
For example: Add a new member to OWNERS in #11046 with a comment that they/she/he is covering for s390.
@dhiller @brianmcarey can help to do this modification

@vamsikrishna-siddu the requested change wrt ownership is still missing. I know that this is currently not possible since you are not (yet) a member of the org, but someone in sig-buildsystem needs to own this.

So I would suggest you apply for KubeVirt membership (see here how to do this), and then we can add you to the org.

I believe we should make an exception for this case wrt/ contributions, and I think this is fair, since addition of a new build architecture is significant enough.

WDYT @fabiand @vladikr @davidvossel ?

Hi @dhiller I am successfully now a member of kubevirt organization. can you please add me to the required special interest group. Thanks

[dhiller]

Howdy.
Please include an OWNERS file to specify who is owning s390 support.
Setting a
/hold
until the file is added.
For example: Add a new member to OWNERS in #11046 with a comment that they/she/he is covering for s390.
@dhiller @brianmcarey can help to do this modification

@vamsikrishna-siddu the requested change wrt ownership is still missing. I know that this is currently not possible since you are not (yet) a member of the org, but someone in sig-buildsystem needs to own this.
So I would suggest you apply for KubeVirt membership (see here how to do this), and then we can add you to the org.
I believe we should make an exception for this case wrt/ contributions, and I think this is fair, since addition of a new build architecture is significant enough.
WDYT @fabiand @vladikr @davidvossel ?

Hi @dhiller I am successfully now a member of kubevirt organization. can you please add me to the required special interest group. Thanks

Hey @vamsikrishna-siddu I'd suggest you create a PR against the OWNERS_ALIASES file in kubevirt/kubevirt, adding you to the sig-buildsystem-reviewers group, maybe with a comment after your name to make clear what you are owning.

[dhiller]

/release-note-edit add s390x support for kubevirt builder

[kubevirt-bot]

New changes are detected. LGTM label has been removed.

[vamsikrishna-siddu]

Hi @fabiand @dhiller ,
with the recent communication in google-groups regarding this PR #11614 . I got that you are planning to implement working-groups to specify the stakeholders for the respective arches. I assume it will take some time to get that feature. meanwhile is it possible to merge this Kubevirt builder pr as it helps us to enable CI and kubevirt on s390x. Once the working-groups feature is out. We can add the contributors there.

[fabiand]

@vamsikrishna-siddu yes, working groups.

It's not a technical feature, it's more about defining ownerhsip, and specific owners, for archtiectures.

Please join the call to speed up this process.

[kubevirt-bot]

@vamsikrishna-siddu: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-kubevirt-e2e-k8s-1.29-sig-storage	82abac1	link	true	/test pull-kubevirt-e2e-k8s-1.29-sig-storage
pull-kubevirt-conformance-arm64	96e4378	link	false	/test pull-kubevirt-conformance-arm64

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.