-
Notifications
You must be signed in to change notification settings - Fork 377
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
: MULTIARCH-4568: Inject ReleaseArch into openshift-install #1792
: MULTIARCH-4568: Inject ReleaseArch into openshift-install #1792
Conversation
Readme: readmeInstallUnix, | ||
InjectReleaseImage: true, | ||
InjectReleaseVersion: true, | ||
InjectReleaseArchitecture: true, |
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.
There are various usage patterns of this command, have you had a chance to check all of them;
- oc adm release info --tools
- oc adm release --command=installer --command=darwing/arm64
...
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.
yes, they will print a warning if the openshift-install doesn't have the right marker, but it will exit 0.
@@ -1041,6 +1056,8 @@ const ( | |||
releaseImageMarker = "!_RELEASE_IMAGE_LOCATION_\x00XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\x00" | |||
// releaseVersionMarker is the placeholder within a binary for the release image version name string. | |||
releaseVersionMarker = "!_RELEASE_VERSION_LOCATION_\x00XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\x00" | |||
// releaseArchitectureMarker is the placeholder within a binary for the list of architectures the release image supports. | |||
releaseArchitectureMarker = "!_RELEASE_ARCHITECTURE_LOCATION_\x00XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\x00" |
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.
We are modifying binaries that are already built and that inevitably causes checksum value changes which is not good with respect to sanity checks. I'm against this change as it additionally modifies installer binary with more data and I believe that this is not the correct way to pass information.
But as far as I understand you can't find any alternative solution and I won't block this PR. I can only suggest that please ensure that the checksum values of the modified binary must be same with the data in the sha256sum file.
I'd like to note that please be aware that with this change, all the new minor version extraction mechanisms for old major version will be affected. For instance, now new 4.14.z installer binary will be embedded with this information and if this funtionality relies on something in newer release payloads, that causes issues. |
@ardaguclu For binaries that don't have the
Maybe there is a way to inspect the binary for this marker before we try to inject the change tho? 🤔 |
That means current status of this PR is causing failures for extractions from older release payloads. Edited: Assuming that there might be places that returns exit code non-zero, when this warning happens.
That looks to me a risky operation comparing to the benefit we are trying to get. |
It throws a warning, but the binary is intact and operational. |
Have you had a chance to check that when this warning is printed, exit code is still zero?. If that is the case, we can move forward. |
Might be hard to see in this output, but the return code is 0:
The tar sha matches as well
|
a872877
to
77c691c
Compare
/retest |
86a2ee1
to
e77658e
Compare
/retest |
1 similar comment
/retest |
I'd like to get some opinions about this patch from the installer as this modifies the installer binary. WDYT? @zaneb |
The installer team will be able to weigh in on openshift/installer#8515. Assuming that is accepted then we'd want this change as well. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ardaguclu, jeffdyoung 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 |
/retitle: MULTIARCH-4568: Inject ReleaseArch into openshift-install |
@jeffdyoung: This pull request references MULTIARCH-4568 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.17.0" version, but no target version was set. In response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
@jeffdyoung: 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. |
[ART PR BUILD NOTIFIER] This PR has been included in build openshift-enterprise-cli-container-v4.17.0-202407090112.p0.ga2e5b09.assembly.stream.el9 for distgit openshift-enterprise-cli. |
In parallel with: openshift/installer#8515
This is necessary so the installer knows if it is using a single arch payload vs a multi arch payload.
ATM customers can't recognize the difference without having to query the container registry.
This is also the first step to enable deploying clusters with ARM control planes and x86 compute nodes (and vice versa)
https://issues.redhat.com/browse/MULTIARCH-4567