enhancements/installer/component-selection: Suggest early annotation presubmits #1174
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
wking
force-pushed
the
pre-api-capabability-annotations
branch
from
4632352 to
40652c8
Compare
bparees
reviewed
Jul 7, 2022
Member
Author
|
Here is an example of me working the checklist in premerge testing for |
…presubmits The outgoing order might result in: 1. There is an existing cluster capability that folks want to make conditional. 2. Bump openshift/api to add newCap, and include it in vCurrent. 3. Bump the CVO vendoring. 4. New preview release is cut, say 4.12.0-fc.1. 5. User installs 4.12.0-fc.1 with None. 6. ClusterVersion claims newCap is disabled, but the cluster still includes all the resources for the associated capability. User is confused. 7. Manifest annotations pull request opened. 8. Presubmits pass on the annotation pull request, because we only run vCurrent presubmits. 9. Manifest annotations land. 10. no-cap CI starts failing, because we forgot to annotate some manifest (e.g. a custom resource did not get annotated, but the backing CustomResourceDefinition did). 11. Additional fixup pull requests while folks sort out annotations and test-suite adjustments to get no-cap CI passing again. This could take a while. 12. The usual post-merge drama like "do we revert or try to roll forward?". Additional pre-releases cut. More confused users asking why 'None' installs are failing, etc. 13. We get everything straightened out. 14. Life goes on. With the new flow, the in-flight testing of annotation changes establishes that: * Clusters can still install without those manifests. * Test suites covered by presubmits (or cluster-bot testing) are compatible with clusters that lack the new capability. And all the drama and shifting needed to move from the initial guess at an implementation to an implementation that actually works in those cases is happening pre-merge, where it only impacts folks who are actively working on the annotations and test-suite changes.
wking
force-pushed
the
pre-api-capabability-annotations
branch
from
40652c8 to
03ed3ad
Compare
Contributor
|
/lgtm |
Contributor
|
/approve |
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bparees The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
Contributor
|
@wking: all tests passed! 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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
The outgoing order might result in:
newCap, and include it invCurrent.None.newCapis disabled, but the cluster still includes all the resources for the associated capability. User is confused.vCurrentpresubmits.Noneinstalls are failing, etc.With the new flow, the in-flight testing of annotation changes establishes that:
And all the drama and shifting needed to move from the initial guess at an implementation to an implementation that actually works in those cases is happening pre-merge, where it only impacts folks who are actively working on the annotations and test-suite changes.
CC @bparees