OSDOCS-18179-bug-batch-olm-4-22#112594
Open
wgabor0427 wants to merge 1 commit into
Open
Conversation
openshift-ci
Bot
added
the
size/S
|
🤖 Tue Jun 02 20:58:45 - Prow CI generated the docs preview: |
wgabor0427
force-pushed
the
OSDOCS-18179-bug-batch-olm-4-22
branch
from
fea6dbc to
95d8556
Compare
Contributor
Author
|
/label merge-review-needed |
openshift-ci
Bot
added
the
merge-review-needed
dfitzmau
added
merge-review-in-progress
dfitzmau
reviewed
Jun 2, 2026
Contributor
dfitzmau
left a comment
dfitzmau
left a comment
There was a problem hiding this comment.
Hi, @wgabor0427 . I added comments inline.
|
|
||
| * Before this update, the `collect-profiles` job was affected by maintenance difficulties, causing confusion for customers and support engineers during troubleshooting. With this release, the `collect-profiles` job is removed, improving user experience and reducing maintenance effort. (link:https://issues.redhat.com/browse/OCPBUGS-31547[OCPBUGS-31547]) | ||
|
|
||
| * Before this update, the `cluster-olm-operator` did not detect version changes during cluster upgrades. As a consequence, the Operator failed to report the `Progressing=True` status during upgrades, which prevented accurate upgrade monitoring. With this release, version detection logic was added that compares RELEASE_VERSION against the stored operator version and sets the `Progressing=True`status when an upgrade is detected. As a result, the Operator correctly reports the `Progressing` status during upgrades, which improves upgrade observability. (link:https://redhat.atlassian.net/browse/OCPBUGS-65623[OCPBUGS-65623]) |
Contributor
There was a problem hiding this comment.
Suggested change
| * Before this update, the `cluster-olm-operator` did not detect version changes during cluster upgrades. As a consequence, the Operator failed to report the `Progressing=True` status during upgrades, which prevented accurate upgrade monitoring. With this release, version detection logic was added that compares RELEASE_VERSION against the stored operator version and sets the `Progressing=True`status when an upgrade is detected. As a result, the Operator correctly reports the `Progressing` status during upgrades, which improves upgrade observability. (link:https://redhat.atlassian.net/browse/OCPBUGS-65623[OCPBUGS-65623]) | |
| * Before this update, the `cluster-olm-operator` did not detect version changes during cluster upgrades. As a consequence, the Operator failed to report the `Progressing=True` status during upgrades, which prevented accurate upgrade monitoring. With this release, version detection logic was added that compares `RELEASE_VERSION` against the stored Operator version and sets the `Progressing=True`status when an upgrade is detected. As a result, the Operator correctly reports the `Progressing` status during upgrades, which improves upgrade observability. (link:https://redhat.atlassian.net/browse/OCPBUGS-65623[OCPBUGS-65623]) |
|
|
||
| * Before this update, the `cluster-olm-operator` did not detect version changes during cluster upgrades. As a consequence, the Operator failed to report the `Progressing=True` status during upgrades, which prevented accurate upgrade monitoring. With this release, version detection logic was added that compares RELEASE_VERSION against the stored operator version and sets the `Progressing=True`status when an upgrade is detected. As a result, the Operator correctly reports the `Progressing` status during upgrades, which improves upgrade observability. (link:https://redhat.atlassian.net/browse/OCPBUGS-65623[OCPBUGS-65623]) | ||
|
|
||
| * Before this update, `NetworkPolicy` egress rules hardcoded port 6443 for `kube-apiserver` access. Because HyperShift allows custom API server ports via the `hostedcluster.spec.networking.apiServer.port`, OLM Operators failed to communicate with `kube-apiserver` in the HyperShift clusters which used non-default API ports. As a consequence, the Operator functionality and catalog operations were broken. With this release, the hardcoded port 6443 is replaced with wildcard egress (egress: [{}]) for `kube-apiserver` traffic. Explicit DNS rules (ports 53, 5353) were also added for documentation and future policy refinements. As a result, OLM now supports HyperShift deployments with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-66980[OCPBUGS-66980]) |
Contributor
There was a problem hiding this comment.
Check with Laura Hinson is HYperShift should be replace by hosted control plane
Contributor
Author
There was a problem hiding this comment.
replaced all Hypershift with hosted control planes
|
|
||
| * Before this update, `NetworkPolicy` egress rules hardcoded port 6443 for `kube-apiserver` access. Because HyperShift allows custom API server ports via the `hostedcluster.spec.networking.apiServer.port`, OLM Operators failed to communicate with `kube-apiserver` in the HyperShift clusters which used non-default API ports. As a consequence, the Operator functionality and catalog operations were broken. With this release, the hardcoded port 6443 is replaced with wildcard egress (egress: [{}]) for `kube-apiserver` traffic. Explicit DNS rules (ports 53, 5353) were also added for documentation and future policy refinements. As a result, OLM now supports HyperShift deployments with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-66980[OCPBUGS-66980]) | ||
|
|
||
| * Before this update, `NetworkPolicy` egress rules in OLM v0 hardcoded port 6443 for `kube-apiserver` access across static manifests and generated policies. Because HyperShift allows custom API server ports that differ from 6443, OLM v0 components (`olm-operator`, `catalog-operator`, `packageserver`) did not communicate with `kube-apiserver` in HyperShift clusters that used custom API ports. As a consequence, operator installation and catalog operations were prevented. With this update, `NetworkPolicy` egress rules are updated to use a wildcard (egress: [{}]) for `kube-apiserver` traffic in both static manifests and dynamic policy generation code. Explicit DNS rules (ports 53, 5353) are also added for future policy refinements. As a result, OLM v0 supports HyperShift deployments with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-76971[OCPBUGS-76971]) |
Contributor
There was a problem hiding this comment.
Suggested change
| * Before this update, `NetworkPolicy` egress rules in OLM v0 hardcoded port 6443 for `kube-apiserver` access across static manifests and generated policies. Because HyperShift allows custom API server ports that differ from 6443, OLM v0 components (`olm-operator`, `catalog-operator`, `packageserver`) did not communicate with `kube-apiserver` in HyperShift clusters that used custom API ports. As a consequence, operator installation and catalog operations were prevented. With this update, `NetworkPolicy` egress rules are updated to use a wildcard (egress: [{}]) for `kube-apiserver` traffic in both static manifests and dynamic policy generation code. Explicit DNS rules (ports 53, 5353) are also added for future policy refinements. As a result, OLM v0 supports HyperShift deployments with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-76971[OCPBUGS-76971]) | |
| * Before this update, `NetworkPolicy` egress rules in OLM v0 hardcoded port 6443 for `kube-apiserver` access across static manifests and generated policies. Because HyperShift allows custom API server ports that differ from 6443, OLM v0 components (`olm-operator`, `catalog-operator`, `packageserver`) did not communicate with `kube-apiserver` in HyperShift clusters that used custom API ports. As a consequence, Operator installation and catalog operations were prevented. With this update, `NetworkPolicy` egress rules are updated to use a wildcard (egress: [{}]) for `kube-apiserver` traffic in both static manifests and dynamic policy generation code. Explicit DNS rules (ports 53, 5353) are also added for future policy refinements. As a result, OLM v0 supports HyperShift deployments with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-76971[OCPBUGS-76971]) |
|
|
||
| * Before this update, the `collect-profiles` job was affected by maintenance difficulties, causing confusion for customers and support engineers during troubleshooting. With this release, the `collect-profiles` job is removed, improving user experience and reducing maintenance effort. (link:https://issues.redhat.com/browse/OCPBUGS-31547[OCPBUGS-31547]) | ||
|
|
||
| * Before this update, the `cluster-olm-operator` did not detect version changes during cluster upgrades. As a consequence, the Operator failed to report the `Progressing=True` status during upgrades, which prevented accurate upgrade monitoring. With this release, version detection logic was added that compares RELEASE_VERSION against the stored operator version and sets the `Progressing=True`status when an upgrade is detected. As a result, the Operator correctly reports the `Progressing` status during upgrades, which improves upgrade observability. (link:https://redhat.atlassian.net/browse/OCPBUGS-65623[OCPBUGS-65623]) |
Contributor
There was a problem hiding this comment.
Suggested change
| * Before this update, the `cluster-olm-operator` did not detect version changes during cluster upgrades. As a consequence, the Operator failed to report the `Progressing=True` status during upgrades, which prevented accurate upgrade monitoring. With this release, version detection logic was added that compares RELEASE_VERSION against the stored operator version and sets the `Progressing=True`status when an upgrade is detected. As a result, the Operator correctly reports the `Progressing` status during upgrades, which improves upgrade observability. (link:https://redhat.atlassian.net/browse/OCPBUGS-65623[OCPBUGS-65623]) | |
| * Before this update, the `cluster-olm-operator` did not detect version changes during cluster upgrades. As a consequence, the Operator failed to report the `Progressing=True` status during upgrades, which prevented accurate upgrade monitoring. With this release, version detection logic was added that compares RELEASE_VERSION against the stored operator version and sets the `Progressing=True` status when an upgrade is detected. As a result, the Operator correctly reports the `Progressing` status during upgrades, which improves upgrade observability. (link:https://redhat.atlassian.net/browse/OCPBUGS-65623[OCPBUGS-65623]) |
|
|
||
| * Before this update, `NetworkPolicy` egress rules in OLM v0 hardcoded port 6443 for `kube-apiserver` access across static manifests and generated policies. Because HyperShift allows custom API server ports that differ from 6443, OLM v0 components (`olm-operator`, `catalog-operator`, `packageserver`) did not communicate with `kube-apiserver` in HyperShift clusters that used custom API ports. As a consequence, operator installation and catalog operations were prevented. With this update, `NetworkPolicy` egress rules are updated to use a wildcard (egress: [{}]) for `kube-apiserver` traffic in both static manifests and dynamic policy generation code. Explicit DNS rules (ports 53, 5353) are also added for future policy refinements. As a result, OLM v0 supports HyperShift deployments with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-76971[OCPBUGS-76971]) | ||
|
|
||
| * Before this update, the `catalog-operator Pod failed during the {sno} cluster install. With this release, the nil pointer dereference in the `sortUnpackJobs` parameter when sorting non-failed jobs is fixed. As a result, the `catalog-operator` Pod does not fail during the cluster install. (link:https://issues.redhat.com/browse/OCPBUGS-77179[OCPBUGS-77179]) |
Contributor
There was a problem hiding this comment.
Suggested change
| * Before this update, the `catalog-operator Pod failed during the {sno} cluster install. With this release, the nil pointer dereference in the `sortUnpackJobs` parameter when sorting non-failed jobs is fixed. As a result, the `catalog-operator` Pod does not fail during the cluster install. (link:https://issues.redhat.com/browse/OCPBUGS-77179[OCPBUGS-77179]) | |
| * Before this update, the `catalog-operator` Pod failed during the {sno} cluster install. With this release, the nil pointer dereference in the `sortUnpackJobs` parameter when sorting non-failed jobs is fixed. As a result, the `catalog-operator` Pod does not fail during the cluster install. (link:https://issues.redhat.com/browse/OCPBUGS-77179[OCPBUGS-77179]) |
dfitzmau
removed
the
merge-review-in-progress
wgabor0427
force-pushed
the
OSDOCS-18179-bug-batch-olm-4-22
branch
from
95d8556 to
7dd630e
Compare
Contributor
Author
|
/label merge-review-needed |
openshift-ci
Bot
added
the
merge-review-needed
Contributor
Author
|
/remove-label merge-review-needed |
openshift-ci
Bot
removed
the
merge-review-needed
wgabor0427
force-pushed
the
OSDOCS-18179-bug-batch-olm-4-22
branch
from
7dd630e to
49b38bd
Compare
Contributor
Author
|
/label merge-review-needed |
openshift-ci
Bot
added
the
merge-review-needed
mburke5678
added
the
merge-review-in-progress
mburke5678
reviewed
Jun 2, 2026
|
|
||
| * Before this update, `NetworkPolicy` egress rules hardcoded port 6443 for `kube-apiserver` access. Because hosted control planes allows custom API server ports via the `hostedcluster.spec.networking.apiServer.port` parameter, OLM Operators failed to communicate with `kube-apiserver` in hosted clusters that used non-default API ports. As a consequence, the Operator functionality and catalog operations were broken. With this release, the hardcoded port 6443 is replaced with wildcard egress (egress: [{}]) for `kube-apiserver` traffic. Explicit DNS rules (ports 53, 5353) were also added for documentation and future policy refinements. As a result, OLM now supports hosted control planes deployments with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-66980[OCPBUGS-66980]) | ||
|
|
||
| * Before this update, `NetworkPolicy` egress rules in OLM v0 hardcoded port 6443 for `kube-apiserver` access across static manifests and generated policies. Because hosted control planes allows custom API server ports that differ from 6443, OLM v0 components (`olm-operator`, `catalog-operator`, `packageserver`) did not communicate with `kube-apiserver` in hosted control planes clusters that used custom API ports. As a consequence, Operator installation and catalog operations were prevented. With this update, `NetworkPolicy` egress rules are updated to use a wildcard (egress: [{}]) for `kube-apiserver` traffic in both static manifests and dynamic policy generation code. Explicit DNS rules (ports 53, 5353) are also added for future policy refinements. As a result, OLM v0 supports HyperShift deployments with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-76971[OCPBUGS-76971]) |
Contributor
There was a problem hiding this comment.
Did you miss one?
Suggested change
| * Before this update, `NetworkPolicy` egress rules in OLM v0 hardcoded port 6443 for `kube-apiserver` access across static manifests and generated policies. Because hosted control planes allows custom API server ports that differ from 6443, OLM v0 components (`olm-operator`, `catalog-operator`, `packageserver`) did not communicate with `kube-apiserver` in hosted control planes clusters that used custom API ports. As a consequence, Operator installation and catalog operations were prevented. With this update, `NetworkPolicy` egress rules are updated to use a wildcard (egress: [{}]) for `kube-apiserver` traffic in both static manifests and dynamic policy generation code. Explicit DNS rules (ports 53, 5353) are also added for future policy refinements. As a result, OLM v0 supports HyperShift deployments with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-76971[OCPBUGS-76971]) | |
| * Before this update, `NetworkPolicy` egress rules in OLM v0 hardcoded port 6443 for `kube-apiserver` access across static manifests and generated policies. Because hosted control planes allows custom API server ports that differ from 6443, OLM v0 components (`olm-operator`, `catalog-operator`, `packageserver`) did not communicate with `kube-apiserver` in hosted control planes clusters that used custom API ports. As a consequence, Operator installation and catalog operations were prevented. With this update, `NetworkPolicy` egress rules are updated to use a wildcard (egress: [{}]) for `kube-apiserver` traffic in both static manifests and dynamic policy generation code. Explicit DNS rules (ports 53, 5353) are also added for future policy refinements. As a result, OLM v0 supports hosted control plane deployments with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-76971[OCPBUGS-76971]) |
Contributor
Author
There was a problem hiding this comment.
I did, sorry. Updated now
mburke5678
reviewed
Jun 2, 2026
|
|
||
| * Before this update, the `cluster-olm-operator` did not detect version changes during cluster upgrades. As a consequence, the Operator failed to report the `Progressing=True` status during upgrades, which prevented accurate upgrade monitoring. With this release, version detection logic was added that compares RELEASE_VERSION against the stored Operator version and sets the `Progressing=True` status when an upgrade is detected. As a result, the Operator correctly reports the `Progressing` status during upgrades, which improves upgrade observability. (link:https://redhat.atlassian.net/browse/OCPBUGS-65623[OCPBUGS-65623]) | ||
|
|
||
| * Before this update, `NetworkPolicy` egress rules hardcoded port 6443 for `kube-apiserver` access. Because hosted control planes allows custom API server ports via the `hostedcluster.spec.networking.apiServer.port` parameter, OLM Operators failed to communicate with `kube-apiserver` in hosted clusters that used non-default API ports. As a consequence, the Operator functionality and catalog operations were broken. With this release, the hardcoded port 6443 is replaced with wildcard egress (egress: [{}]) for `kube-apiserver` traffic. Explicit DNS rules (ports 53, 5353) were also added for documentation and future policy refinements. As a result, OLM now supports hosted control planes deployments with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-66980[OCPBUGS-66980]) |
Contributor
There was a problem hiding this comment.
"hosted control planes deployments" doesn't sound grammatically correct. Do you know if "deploying hosted control planes" is technically correct?
Suggested change
| * Before this update, `NetworkPolicy` egress rules hardcoded port 6443 for `kube-apiserver` access. Because hosted control planes allows custom API server ports via the `hostedcluster.spec.networking.apiServer.port` parameter, OLM Operators failed to communicate with `kube-apiserver` in hosted clusters that used non-default API ports. As a consequence, the Operator functionality and catalog operations were broken. With this release, the hardcoded port 6443 is replaced with wildcard egress (egress: [{}]) for `kube-apiserver` traffic. Explicit DNS rules (ports 53, 5353) were also added for documentation and future policy refinements. As a result, OLM now supports hosted control planes deployments with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-66980[OCPBUGS-66980]) | |
| * Before this update, `NetworkPolicy` egress rules hardcoded port 6443 for `kube-apiserver` access. Because hosted control planes allows custom API server ports via the `hostedcluster.spec.networking.apiServer.port` parameter, OLM Operators failed to communicate with `kube-apiserver` in hosted clusters that used non-default API ports. As a consequence, the Operator functionality and catalog operations were broken. With this release, the hardcoded port 6443 is replaced with wildcard egress (egress: [{}]) for `kube-apiserver` traffic. Explicit DNS rules (ports 53, 5353) were also added for documentation and future policy refinements. As a result, OLM now supports deploying hosted control planes with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-66980[OCPBUGS-66980]) |
Contributor
Author
There was a problem hiding this comment.
I think deploying sounds much better
mburke5678
reviewed
Jun 2, 2026
|
|
||
| * Before this update, `NetworkPolicy` egress rules in OLM v0 hardcoded port 6443 for `kube-apiserver` access across static manifests and generated policies. Because hosted control planes allows custom API server ports that differ from 6443, OLM v0 components (`olm-operator`, `catalog-operator`, `packageserver`) did not communicate with `kube-apiserver` in hosted control planes clusters that used custom API ports. As a consequence, Operator installation and catalog operations were prevented. With this update, `NetworkPolicy` egress rules are updated to use a wildcard (egress: [{}]) for `kube-apiserver` traffic in both static manifests and dynamic policy generation code. Explicit DNS rules (ports 53, 5353) are also added for future policy refinements. As a result, OLM v0 supports HyperShift deployments with any configured API server port. (link:https://redhat.atlassian.net/browse/OCPBUGS-76971[OCPBUGS-76971]) | ||
|
|
||
| * Before this update, the `catalog-operator` Pod failed during the {sno} cluster install. With this release, the nil pointer dereference in the `sortUnpackJobs` parameter when sorting non-failed jobs is fixed. As a result, the `catalog-operator` Pod does not fail during the cluster install. (link:https://issues.redhat.com/browse/OCPBUGS-77179[OCPBUGS-77179]) |
Contributor
There was a problem hiding this comment.
Suggested change
| * Before this update, the `catalog-operator` Pod failed during the {sno} cluster install. With this release, the nil pointer dereference in the `sortUnpackJobs` parameter when sorting non-failed jobs is fixed. As a result, the `catalog-operator` Pod does not fail during the cluster install. (link:https://issues.redhat.com/browse/OCPBUGS-77179[OCPBUGS-77179]) | |
| * Before this update, the `catalog-operator` pod failed during the {sno} cluster install. With this release, the nil pointer dereference in the `sortUnpackJobs` parameter when sorting non-failed jobs is fixed. As a result, the `catalog-operator` Pod does not fail during the cluster install. (link:https://issues.redhat.com/browse/OCPBUGS-77179[OCPBUGS-77179]) |
Contributor
Author
There was a problem hiding this comment.
I fixed both "Pods"
Contributor
|
@wgabor0427 A couple more nits. Sorry! |
wgabor0427
force-pushed
the
OSDOCS-18179-bug-batch-olm-4-22
branch
from
49b38bd to
870f011
Compare
mburke5678
added
ok-to-merge
and removed
merge-review-in-progress
|
@wgabor0427: 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-sigs/prow repository. I understand the commands that are listed here. |
Contributor
Author
|
/label merge-review-needed |
openshift-ci
Bot
added
the
merge-review-needed
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 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.
Version(s):
4.22
Issue:
https://redhat.atlassian.net/browse/OSDOCS-18179
Link to docs preview:
https://112594--ocpdocs-pr.netlify.app/openshift-enterprise/latest/release_notes/ocp-4-22-release-notes.html#rn-ocp-release-note-olm-fixed-issues_release-notes
QE review:
Additional information: