-
Notifications
You must be signed in to change notification settings - Fork 200
POC - include kubevirt's virt-operator in a custom release payload #532
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
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There's no straightforward way to get the installer pinned RHCOS version from an installer binary or a release payload, so let's not become reliant on this. We can easily pin dev-scripts to the correct RHCOS image each time we pin to a new release payload. Also, ultimately we need to get away from this way of caching a pre-defined RHCOS image version - we instead need a way of caching whatever version is driven by either openshift-install or machine config upgrades.
Now that we can build and publish release payloads with our installer fork, let's consume the installer the same way stock installer builds are intended to be consumed - by extracting it from the release payload. Note - we use extract --command=openshift-install to avoid roundtrip to tar.gz involved with using --tools.
Use mktemp --tmpdir so we use /tmp, remove the image-references file from tmpdir when we're done with it, move the wait_for_tag() function, and change wait_for_tag() to not wait for a specific image digest.
This is a manifest of all of the images referenced in this dir.
This will also 'oc adm release new' to change the manifests to the images referenced by the release payload, and also will ensure that 'oc adm release mirror' will be able to change the manifests to point at the mirrored images.
This asks it to create/update a ClusterOperator resource.
This takes an existing image, adds manifests, and adds the io.openshift.release.operator label.
Allow passing a list of operators which we will then tag into the image stream, and also tag all of the dependencies listed in their manifests.
Contributor
Author
|
Closing this. I'm not proposing actually merging this, it was just a prototype |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is proof-of-concept showing how virt-operator could be adapted to work as an OpenShift ClusterOperator, and be included in a custom release payload:
Note: this builds on #401