-
Notifications
You must be signed in to change notification settings - Fork 211
chore: Support multi-arch containers build #461
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Hi @kahirokunn. Thanks for your PR. I'm waiting for a aws-controllers-k8s member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If ACK is going to support multi-arch, I feel like it should support the following
PLATFORMS=linux
ARCHITECTURES=amd64 arm64 ppc64le s390x
Also, this would not be the only change to support this (possibly the release jobs/templates might need to change? I'm unsure?)
But at a mimium, if we change this, we should also claim support also update the CSV template to whatever arch's the core maintainers decide to support.
Sample of what that would look like:
labels:
operatorframework.io/arch.s390x: supported
operatorframework.io/os.zos: supported
operatorframework.io/os.linux: supported
operatorframework.io/arch.amd64: supported
operatorframework.io/os.linux: supported
operatorframework.io/arch.ppc64le: supported
operatorframework.io/os.linux: supported
operatorframework.io/arch.arm64: supported
File needing updating is here. This would be for metadate.labels
field.
If I do them would you please incorporate the PR? |
@kahirokunn I'm not a maintainer of ACK, I'm just a contributor. |
224ea2c
to
7fecb89
Compare
@acornett21 I have responded to all the suggestions you have given me. Are they as intended? |
@a-hilaly Hi! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
operatorframework.io/arch.s390x: supported | ||
operatorframework.io/arch.amd64: supported | ||
operatorframework.io/arch.ppc64le: supported | ||
operatorframework.io/arch.arm64: supported | ||
operatorframework.io/os.linux: supported | ||
operatorframework.io/os.zos: supported |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not familiar of operatorframework, why are these needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@a-hilaly I am not sure either, but they asked me to put it on, so I did.
I don't think this means anything. Do you want me to remove it?
#461 (review)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it makes sense, so I will remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I asked for this, since if ACK is going to distribute a multi-arch image, in order for ACK to be available on architectures other then amd64, this enables the operator to be listed on those clusters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see in another comment, that power/s390x aren't supported by the eks container image that ACK uses, for now we should just have
operatorframework.io/os.linux: supported
operatorframework.io/arch.amd64: supported
operatorframework.io/os.linux: supported
operatorframework.io/arch.arm64: supported
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have tested it and it works without it, because the container image supports manifest lists!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kahirokunn This has nothing to do with the container. This is needed for distribution of the operator bundles to OLM once released. These annotations instruct the catalog-operator in a cluster what operators can be installed for what architectures. If we leave off these annotations, then the operator will not be able to be installed on any ARM OLM distribution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@acornett21
I think it is backward compatible since it is not annotated from the beginning.
I have never used OperatorFramework at all, so I don't know how to test it or anything.
Could you please open a PR for OperatorFramework yourself?
Thank you 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kahirokunn Please do not resolve this, this is needed like mentioned. Please include this in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@a-hilaly
I put it in because it was requested, but does it seem to be a problem?
Happy to help bringing more utilities that will help you build ARM images, let's just make sure that it's done in a way that it's not breaking other system |
7fecb89
to
b6164bf
Compare
I have built it with the arm64 platform added and actually run it in an EKS environment and it works very well. |
11041e2
to
b415c8b
Compare
@acornett21 If you create a PR for eks-distro-build-tooling, we will also support the additional platform you specify at that time. Thx 🙏
|
@a-hilaly Do you know why the error occurs? 😢
|
@kahirokunn not very sure but i suspect |
Now I know why.
|
b415c8b
to
ef014dd
Compare
@a-hilaly aws-controllers-k8s/test-infra#383 |
ef014dd
to
165abfa
Compare
/test all |
/retest |
@a-hilaly Hello! What do I need to do to advance this PR? |
6eecc90
to
73c8953
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @kahirokunn !! One last thing.. and we can merge it
…o use TARGETARCH instead of go_arch to facilitate multi-platform build. Signed-off-by: kahirokunn <[email protected]>
73c8953
to
ea924e2
Compare
Signed-off-by: kahirokunn <[email protected]>
/retest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/lgtm cancel |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: a-hilaly, kahirokunn 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:
Approvers can indicate their approval by writing |
/retest |
I have tried to start several controllers of aws-controllers-k8s on an ARM EC2 on AWS, but I get the following error.
To determine the binary format in the Dockerfile, we decided to use TARGETARCH instead of go_arch to facilitate multi-platform build.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.