OCPSTRAT-2876: Allow inclusion/exclusion of manifests based on the OCP major version#1282
OCPSTRAT-2876: Allow inclusion/exclusion of manifests based on the OCP major version#1282JoelSpeed wants to merge 1 commit intoopenshift:mainfrom
Conversation
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
|
Important Review skippedAuto reviews are limited based on label configuration. 🚫 Excluded labels (none allowed) (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the
✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: JoelSpeed 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 |
JoelSpeed
force-pushed
the
major-version-inclusion
branch
2 times, most recently
from
39354c8 to
ef0e8c6
Compare
JoelSpeed
changed the title
openshift-ci-robot
added
the
jira/valid-reference
|
@JoelSpeed: This pull request references OCPSTRAT-2876 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 feature to target the "4.22.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
JoelSpeed
force-pushed
the
major-version-inclusion
branch
from
ef0e8c6 to
2d6aae6
Compare
|
@JoelSpeed: This pull request references OCPSTRAT-2876 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 feature to target the "4.22.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
JoelSpeed
changed the title
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
|
@DavidHurta If you are available, I'd appreciate if you could help me with this feature as well |
|
@JoelSpeed, I will be happy to assist. /cc |
|
@JoelSpeed: 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-sigs/prow repository. I understand the commands that are listed here. |
DavidHurta
left a comment
DavidHurta
left a comment
There was a problem hiding this comment.
The PR looks solid!
A few comments about a thing here or there, but nothing drastic.
The overall functionality is 👍
| ImageRef *imagev1.ImageStream | ||
|
|
||
| Architecture string | ||
| MajorVersion *uint64 |
There was a problem hiding this comment.
Here, the purpose of MajorVersion is starting to become a bit fuzzy in comparison to the Release.Version field. The meaning of MajorVersion in the inclusion filtering context is clear; however, here we use it in a general struct type representing the contents of a release image. Thus, their purpose becomes less clear.
We could do one of the following:
- Document
MajorVersionfield to make the difference betweenRelease.VersionandMajorVersionclearer. - Leave only one source of truth (that is,
Release.Version), and extract the major version when needed using a function. - Create a new field
ParsedVersion semver.Version; we could use it to get access to the parsed cached version of the update easily. This could even be utilized in the future when we need easy access to the parsed version of an update, which is more handy for fine grained processing. This would bring additional value to the new field, make it more general, and make its distinction clearer. The call sites requiring theMajorVersionwould need to be updated to justptr.To(payload.ParsedVersion.Major), so it would still be readable. I am more inclined towards this approach, but I am curious what you think.
| return requiredFeatureSet, enabledFeatureGates, nil | ||
| } | ||
|
|
||
| func loadReleaseVersion(releaseDir string) (semver.Version, error) { |
There was a problem hiding this comment.
Here we start to duplicate some logic. I am curious whether we could leverage the existing loadReleaseMetadata function here instead of manually loading the release version.
The loadReleaseMetadata function also contains some additional validation, such as:
if metadata.Kind != "cincinnati-metadata-v0" {
return release, fmt.Errorf("unrecognized Cincinnati metadata kind %q", metadata.Kind)
}There was a problem hiding this comment.
Something like:
func loadReleaseVersion(releaseDir string) (semver.Version, error) {
release, err := loadReleaseMetadata(releaseDir)
if err != nil {
return semver.Version{}, err
}
parsedVersion, err := semver.Parse(release.Version)
if err != nil {
return semver.Version{}, err
}
return parsedVersion, nil
}| } | ||
| } | ||
|
|
||
| func TestRenderDirWithMajorVersionFiltering(t *testing.T) { |
There was a problem hiding this comment.
Comment not related to the selected line
Thank you for the complex testing of the rendering!
The overall testing coverage of the PR is solid. However, we do not have an integration test to determine whether the CVO will actually apply the manifest based on the major version. I am doubtful whether this feature will receive end-to-end tests. Thus, I think it would be beneficial to increase the test coverage to ensure that the CVO truly does respect the major version when loading and applying manifests, WDYT?
Something like: DavidHurta@ee1907b
3 participants
This introduces a new CVO manifest filter based on the OCP major version.
The intended usage would allow folks to say "this manifest should be deployed on OCP 5 and skipped on OCP 4"
The library-go component here is limiting this feature to FeatureGate and CustomResourceDefinition only for now.
This is not intended for use beyond the feature gating mechanisms we have today. We expect FeatureGate and CustomResourceDefinition yamls to vary by release, but all other inclusion/exclusion should be handled by existing mechanisms like the feature-gate inclusion mechanism.
Example usage: