images: decouple installer and installer-artifacts#7159
images: decouple installer and installer-artifacts#7159patrickdillon wants to merge 2 commits intoopenshift:masterfrom
Conversation
The installer-artifacts image depends on the installer image, which means they cannot be built in parallel. The effect of this dependency is that the installer-artifacts image contains the linux amd64 builds in addition to the mac/linux amd64/arm64 builds present in the installer-artifacts image. Breaking the dependency results in a more efficient build process because they can be built in parallel as well as no duplication of the linux amd64 binary in the release image (before this change the binary would be present in both images within the release image). The risk, though, is that clients are inconsistently grabbing the linux amd64 binary from either image, rather than only the installer image, in which case we would break any client trying to get that binary from the installer-artifacts image.
|
Regarding my concern
It appears we would not break |
|
[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. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Depends on openshift/release#38975 |
|
/hold as WIP. This PR is intended for discussion. |
openshift-ci
Bot
added
the
do-not-merge/hold
|
/retest |
|
I believe this is related: https://issues.redhat.com/browse/CORS-2606 |
I don't see much connection here. This PR is about how we build and deliver the installer for different archs and OSes; and this is independent of the openshift release image. CORS-2606 is about breaking the dependency between the installer and the release image, so this PR wouldn't affect that. |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
Bot
added
the
lifecycle/stale
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
openshift-ci
Bot
added
lifecycle/rotten
|
@patrickdillon: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
openshift-merge-robot
added
the
needs-rebase
|
PR needs rebase. DetailsInstructions 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. |
1 similar comment
|
PR needs rebase. DetailsInstructions 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. |
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closed this PR. DetailsIn 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 kubernetes/test-infra repository. |
5 participants
The installer-artifacts image depends on the installer image, which means they cannot be built in parallel. The effect of this dependency is that the installer-artifacts image contains the linux amd64 builds in addition to the mac/linux amd64/arm64 builds present in the installer-artifacts image.
Breaking the dependency results in a more efficient build process because they can be built in parallel as well as no duplication of the linux amd64 binary in the release image (before this change the binary would be present in both images within the release image).
The risk, though, is that clients are inconsistently grabbing the linux amd64 binary from either image, rather than only the installer image, in which case we would break any client trying to get that binary from the installer-artifacts image.
Will open an accompanying PR in the release repo.