OTA-1010: extract included manifests with net-new capabilities #1958
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@hongkailiu: This pull request references OTA-1010 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 story to target the "4.19.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. |
openshift-ci
bot
added
the
do-not-merge/work-in-progress
hongkailiu
force-pushed
the
OTA-1010-refactor-callback
branch
5 times, most recently
from
ad75be6 to
38aeb1d
Compare
|
@hongkailiu: This pull request references OTA-1010 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 story to target the "4.19.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. |
hongkailiu
force-pushed
the
OTA-1010-refactor-callback
branch
2 times, most recently
from
69216c5 to
916427e
Compare
|
@hongkailiu: This pull request references OTA-1010 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 story to target the "4.19.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. |
hongkailiu
force-pushed
the
OTA-1010-refactor-callback
branch
from
916427e to
27e03eb
Compare
hongkailiu
changed the title
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
|
/retest-required |
|
/cc |
hongkailiu
force-pushed
the
OTA-1010-refactor-callback
branch
4 times, most recently
from
c1909d5 to
0431ce4
Compare
|
/retest-required |
Some testing result from 0431ce4 (outdated)Cluster-bot:
|
|
/retest-required |
|
/test e2e-agnostic-ovn-cmd |
|
/uncc I am not paying attention OTA-1010 matter that much b/c afaik Trevor is involved in this, so I uncc myself to avoid giving false impression that I plan to review here. If my review or approval is necessary, feel free to /cc me again. |
hongkailiu
force-pushed
the
OTA-1010-refactor-callback
branch
2 times, most recently
from
99cda00 to
def90a6
Compare
|
Rerun the test with def90a6: The cluster did not set Comparing with #1958 (comment), no caps became implicitly enabled as expected. Because they would be (explicitly) enabled with I wanted to try But cluster-bot is not so happy with the command. I expect to see some implicitly enabled caps there. Update on May 20. When the rehearsal job came to Then login to the build farm to get the kubeconfig to the ephemeral cluster: Repeat the above test: The logs look good to me. |
|
/test e2e-agnostic-ovn-cmd |
|
@hongkailiu: No presubmit jobs available for openshift/oc@master 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 kubernetes-sigs/prow repository. |
|
/retest-required |
hongkailiu
force-pushed
the
OTA-1010-refactor-callback
branch
from
0be8d41 to
88d0075
Compare
|
/cc |
There was a problem hiding this comment.
I only went through the pkg/cli/admin/release/extract.go diff and left some comments. The code is very hard to read, which is not your fault - it is mostly caused by constructing a series of very long anonymous callbacks that end up being called at whatever time later... Not sure what to do about it though. It would definitely help if this was a series of smaller PRs.
pkg/cli/admin/release/extract.go
Outdated
| if c := imageConfig.Config; c != nil { | ||
| if v, ok := c.Labels["io.openshift.release"]; ok { | ||
| klog.V(2).Infof("Retrieved the version from image configuration in the image to extract: %s", v) | ||
| versionInImageConfig = v |
There was a problem hiding this comment.
Can this callback be called multiple times, overwriting previous values in `versionInImageConfig``? If yes, can the callback be called in parallel, which would be a race?
There was a problem hiding this comment.
If I understand it correctly, oc adm release extract has only one release to extract and one image means one image config.
From my test, it is called only once.
There was a problem hiding this comment.
Can we encode that assumption and blow up with a panic or Fatal if versionInImageConfig is already set?
There was a problem hiding this comment.
The code has been moved to https://github.com/openshift/oc/pull/2050/files.
But I will keep this open because I did not address this comment and you might still think I should do it in this pull.
The concern is valid in general but it is unlikely to happen here.
The other callbacks of extract.ExtractOptions are not multi-thread safe either.
|
It may be beyond the scope of what this PR attempts to do, but I have a feeling that the code could be made more readable if some of callbacks (that are currently lambdas using various option struct members and closures on the surrounding scope variables) were extracted into a dedicated, named and documented single-purpose types with methods that would be used as the callbacks, with a constructor that makes the callback inputs a specified interface. |
I will give this a try. |
There are two files `image-references`, and `release-metadata` that are handled differently from manifest files. When those files come, their readers from the upstream are sent to the downstream callback right away. Other files contain manifests. They are parsed out and then sent to the downstream. We will embed more changes into this part, e.g., collecting all manifests in the image and then use them to calculate the enabled capabilities which is sent as an argument to the downstream callback. Those changes are coming in other pulls.
hongkailiu
force-pushed
the
OTA-1010-refactor-callback
branch
from
88d0075 to
3aacfdd
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: hongkailiu The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
hongkailiu
force-pushed
the
OTA-1010-refactor-callback
branch
2 times, most recently
from
dae1d70 to
d95f37c
Compare
|
@hongkailiu: This pull request references OTA-1010 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 story to target the "4.20.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. |
openshift-ci
bot
added
the
do-not-merge/hold
hongkailiu
force-pushed
the
OTA-1010-refactor-callback
branch
from
d95f37c to
1f0a027
Compare
Before this full, the logging was only for the case that `findClusterIncludeConfigFromInstallConfig` is called, i.e., the path from an install-config file is provided. This pull extends it to the case where the configuration is taken from the current cluster. Another change from the pull is that the logging messages include the target version that is determined by inspecting the release image. The implementation for this is adding a new callback `ImageConfigCallback`.
The `ManifestInclusionConfiguration` is used to determine is a manifest is included on a cluster. Its `Capabilities` field takes the implicitly enabled capabilities into account. This change removes the workaround that handles the net-new capabilities introduced by a cluster upgrade. E.g. if a cluster is currently with 4.13, then it assumes that the capabilities "build", "deploymentConfig", and "ImageRegistry" are enabled. This is because the components underlying those capabilities are installed by default on 4.13, or earlier and cannot be disabled once installed. Those capabilities will become enabled after upgrade from 4.13 to 4.14: either explicitly or implicitly depending on the current value of `cv.spec.capabilities.baselineCapabilitySet`. https://github.com/openshift/oc/blob/e005223acd7c478bac070134c16f5533a258be12/pkg/cli/admin/release/extract_tools.go#L1241-L1252 CVO has already defined the function GetImplicitlyEnabledCapabilities that calculates the implicitly enabled capabilities of a cluster after a cluster upgrade. For this function to work, we have to provide * the manifests that are currently included on the cluster. * the manifests from the payload in the upgrade image. The existing `ManifestReceiver` is enhanced in a way that it can provide enabled capabilities, including both explicit and implicit ones, when the callback to downstream is called. It is implemented by a cache to collect manifests from the upstream and calls downstream only when all manifests are collected and the capabilities are calculated with them using the function `GetImplicitlyEnabledCapabilities` mentioned earlier. This enhancement can be opted in by setting up the `needEnabledCapabilities` field of `ManifestReceiver`. Otherwise, its behaviours stays the same as before. In case that the inclusion configuration is taken from the cluster, i.e., `--install-config` is not set, `needEnabledCapabilities` is set to `true`.
hongkailiu
force-pushed
the
OTA-1010-refactor-callback
branch
from
1f0a027 to
76338a7
Compare
The
ManifestInclusionConfigurationis used todetermine is a manifest is included on a cluster.
Its
Capabilitiesfield takes the implicitly enabledcapabilities into account.
This change removes the workaround that handles the
net-new capabilities introduced by a cluster upgrade.
E.g. if a cluster is currently with 4.13, then it
assumes that the capabilities "build",
"deploymentConfig", and "ImageRegistry" are enabled.
This is because the components underlying those
capabilities are installed by default on 4.13, or
earlier and cannot be disabled once installed. Those
capabilities will become enabled after upgrade from
4.13 to 4.14: either explicitly or implicitly
depending on the current value of
cv.spec.capabilities.baselineCapabilitySet.oc/pkg/cli/admin/release/extract_tools.go
Lines 1241 to 1252 in e005223
CVO has already defined the function
GetImplicitlyEnabledCapabilities that calculates
the implicitly enabled capabilities of a cluster
after a cluster upgrade. For this function to work,
we have to provide
cluster.
The existing
ManifestReceiveris enhanced in a waythat it can provide enabled capabilities, including
both explicit and implicit ones, when the callback to
downstream is called. It is implemented by a cache to
collect manifests from the upstream and calls
downstream only when all manifests are collected and
the capabilities are calculated with them using the
function
GetImplicitlyEnabledCapabilitiesmentionedearlier.
This enhancement can be opted in by setting up the
needEnabledCapabilitiesfield ofManifestReceiver.Otherwise, its behaviours stays the same as before.
In case that the inclusion configuration is taken
from the cluster, i.e.,
--install-configis not set,needEnabledCapabilitiesis set totrue.