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
Add arm64 support #4870
Add arm64 support #4870
Conversation
yselkowitz
commented
Apr 23, 2021
- Add ARM architecture types
- Fix libvirt cluster destroy on ARM
- Add ARM support to AWS installation
- cmd/openshift-install: Add architecture as an option for install-config
- Make order of install-config questions more consistent
- aws: treat a1 as backup to m6g
- Add Makefile
- Add rhcos-stream data for aarch64
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
0eeefaa
to
e90ddac
Compare
/retest |
This PR is covering a lot of changes, some of which are independent from each other. Please separate into discrete PRs that can be discussed on their own. Also, please add references to enhancements or Jira cards that provide more context for these changes. |
f147d32
to
804d1ed
Compare
Seems sane to me to split out the rhcos stream data commit FWIW. |
Only if that would be expedited, because the rest of this won't work without it. |
I don't care about separating that out. It is non-controversial. I just want to separate out the stuff that is controversial so that we can have discussions about those separately. And note that nothing can be merged for another 4 weeks anyway. |
Added an initial attempt to drop the survey question in favour of deriving based on payload architecture (assumed from the build host). |
d037c87
to
7c17d00
Compare
hack/build.sh
Outdated
@@ -16,8 +16,9 @@ fi | |||
MODE="${MODE:-release}" | |||
GIT_COMMIT="${SOURCE_GIT_COMMIT:-$(git rev-parse --verify 'HEAD^{commit}')}" | |||
GIT_TAG="${BUILD_VERSION:-$(git describe --always --abbrev=40 --dirty)}" | |||
HOSTARCH="$(go env GOHOSTARCH)" |
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.
ok so iiuc - the architecture is now set to the host architecture if built manually and set to the architecture of the payload if it is extracted from the payload? so if i actually custom build the installer on an ARM laptop it would set the architecture in the install-config to arm64 - but which might not match the payload architecture necessarily.
Also note that someone could still override the payload using OPENSHIFT_RELEASE_IMAGE_OVERRIDE. so if these are called out it should make things clear for upstream as well as downstream.
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 understand why this would be the correct architecture to select. Why should the architecture of the host where the installer is built effect the architecture of the cluster? I would expect the cluster architecture to default to amd64 to retain current behavior.
/retest |
1 similar comment
/retest |
Any idea why the openstack tests are failing so quickly? |
They were broken by #4999. |
Any remaining issues to address here? |
/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.
Looks good save for a couple nits. Let's squash this down into one or a few commits.
squashed the later commits relating to fixes in the comments. |
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.
Please put the changes in the last commit into their appropriate earlier commits. I do not want a commit in the history that is "miscellaneous fixes".
All installer binaries extracted from a payload, regardless of their runtime OS or architecture, are built on the payload architecture. Therefore, GOHOSTARCH can be used to assume the cluster architecture for which its payload was built. This is set through the Dockerfiles so that manual builds of installer will continue to default to amd64.
@yselkowitz: The following tests failed, say
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/test-infra repository. I understand the commands that are listed here. |
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
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: staebler 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 |