OCPBUGS-25798,OCPBUGS-25802: [release-4.15] NO-ISSUE: Synchronize From Upstream Repositories #643
Conversation
|
@openshift-cherrypick-robot: Jira Issue OCPBUGS-24526 has been cloned as Jira Issue OCPBUGS-25798. Will retitle bug to link to clone. 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/test-infra repository. |
|
/retitle oops |
openshift-ci
bot
changed the title
At the time of making this commit, the package `github.com/ghodss/yaml` is no longer actively maintained. `sigs.k8s.io/yaml` is a permanent fork of `ghodss/yaml` and is actively maintained by Kubernetes SIG. Reference: operator-framework/api#308 Signed-off-by: Eng Zer Jun <engzerjun@gmail.com> Upstream-repository: operator-registry Upstream-commit: 6df3abad48bb338b51986cc89877d89fc1b3e39d
…e (bundle, channel, package) (#1172) Signed-off-by: Rashmi Gottipati <chowdary.grashmi@gmail.com> Upstream-repository: operator-registry Upstream-commit: e5dca1a649fae543cb1caa12ae15dd5163442321
Signed-off-by: Rashmi Gottipati <chowdary.grashmi@gmail.com> Upstream-repository: operator-registry Upstream-commit: cf1db12e386a789cac32b228230f60765597cc8b
In the past, OLM moved to using a label selector to filter the informers that track ConfigMaps in the cluster. However, when this was done, previous ConfigMaps on the cluster that already existed were not labelled. Therefore, on old clusters there is a mix of data - ConfigMaps that OLM created and managed but has now forgotten since they are missing labels, and conformant objects with the label. We use ConfigMaps to track whether or not Jobs should be labelled - if a Job has an OwnerReference to a ConfigMap and the ConfigMap has an OwnerReference to an OLM GVK, we know that the Job is created and managed by OLM. During runtime, the two-hop lookup described above is done by using a ConfigMap informer, so we're light on client calls during the labelling phase of startup. However, before the recent labelling work went in, the ConfigMap informer was *already* filtered by label, so our lookups were dead-ends for the few old ConfigMaps that had never gotten labels in the past. However, on startup we use live clients to determine if there are unlabelled objects we need to handle, so we end up in a state where the live lookup can detect the errant Jobs but the informer-based labellers can't see them as needing labels. This commit is technically a performance regression, as it reverts the unequivocal ConfigMap informer filtering - we see all ConfigMaps on the cluster during startup, but continue to filter as expected once everything has labels. Ideally, we can come up with some policies for cleanup of things like these Jobs and ConfigMaps in the future; at a minimum all of the OLM objects should be labelled and visible to the OLM operators from here on out. Signed-off-by: Steve Kuznetsov <skuznets@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 8a68d79f7f7e7190a5e5b8d1fc6fc5a16e646053
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 7a056b2fab2068f5593d43efd7c3fb87bb2aefab
ConfigMaps provided for the internal source type are user-created and won't have our labels, so we need to use a live client to fetch them. Signed-off-by: Steve Kuznetsov <skuznets@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 79b4d4150180456767b676a75939d124d3783386
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: 98fe8e536ed6298e4037fbaeb211fb91b8e25f83
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: e2b37687f1311f8e5fe1ec508d33c1cd7ac030a3
…ead of the CatalogSource Namespace. Signed-off-by: Daniel Franz <dfranz@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: d70de0797c1604cb2b6d6aa043e1e7731fc830e3
Our controllers must not share runtime with controllers of previous versions, as we expect that the set of actors on the cluster to be coherent with respect to what they're trying to do. RollingUpdate strategies do not guarantee this and lead to cases where previous versions of the operators issue spurious mutating calls that the current operator needs to un-do. Signed-off-by: Steve Kuznetsov <skuznets@redhat.com> Upstream-repository: operator-lifecycle-manager Upstream-commit: cee062283539d08f25333bfa53b2963725e35914
openshift-cherrypick-robot
force-pushed
the
cherry-pick-627-to-release-4.15
branch
from
547932e
to
0671ad9
Compare
|
/retitle OCPBUGS-25798: [release-4.15] NO-ISSUE: Synchronize From Upstream Repositories |
|
/jira cherrypick OCPBUGS-25448 |
|
@stevekuznetsov: Jira Issue OCPBUGS-25448 has been cloned as Jira Issue OCPBUGS-25802. Will retitle bug to link to clone. 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/test-infra repository. |
openshift-ci-robot
added
jira/severity-critical
|
@openshift-cherrypick-robot: This pull request references Jira Issue OCPBUGS-25802, which is valid. The bug has been moved to the POST state. 6 validation(s) were run on this bug
Requesting review from QA contact: The bug has been updated to refer to the pull request using the external bug tracker. 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/test-infra repository. |
|
/retitle OCPBUGS-25798,OCPBUGS-25802: [release-4.15] NO-ISSUE: Synchronize From Upstream Repositories |
openshift-ci
bot
changed the title
openshift-ci-robot
removed
the
jira/valid-bug
openshift-ci-robot
added
the
jira/invalid-bug
|
@openshift-cherrypick-robot: This pull request references Jira Issue OCPBUGS-25798, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. This pull request references Jira Issue OCPBUGS-25802, which is valid. 6 validation(s) were run on this bug
Requesting review from QA contact: The bug has been updated to refer to the pull request using the external bug tracker. 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/test-infra repository. |
|
/jira refresh |
openshift-ci-robot
added
jira/valid-bug
|
@stevekuznetsov: This pull request references Jira Issue OCPBUGS-25798, which is valid. The bug has been moved to the POST state. 6 validation(s) were run on this bug
Requesting review from QA contact: This pull request references Jira Issue OCPBUGS-25802, which is valid. 6 validation(s) were run on this bug
Requesting review from QA contact: 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/test-infra repository. |
|
/test verify |
|
@openshift-cherrypick-robot: The following test failed, say
Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ncdc, openshift-cherrypick-robot The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
/label backport-risk-assessed |
openshift-ci
bot
added
the
backport-risk-assessed
openshift-ci
bot
assigned bandrade, emmajiafan, jianzhangbjz, KeenonLee, kuiwang02 and Xia-Zhao-rh
|
/label cherry-pick-approved |
openshift-ci
bot
added
the
cherry-pick-approved
|
Merging manually to get past test flakes. |
|
@openshift-cherrypick-robot: Jira Issue OCPBUGS-25798: All pull requests linked via external trackers have merged: Jira Issue OCPBUGS-25798 has been moved to the MODIFIED state. Jira Issue OCPBUGS-25802: All pull requests linked via external trackers have merged: Jira Issue OCPBUGS-25802 has been moved to the MODIFIED state. 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/test-infra repository. |
|
[ART PR BUILD NOTIFIER] This PR has been included in build operator-lifecycle-manager-container-v4.15.0-202312211752.p0.g7077fe6.assembly.stream for distgit operator-lifecycle-manager. |
|
Fix included in accepted release 4.15.0-0.nightly-2023-12-21-211153 |
This is an automated cherry-pick of #627
/assign stevekuznetsov