-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add OLM 1.0 relnote for 4.14 #63605
Add OLM 1.0 relnote for 4.14 #63605
Conversation
🤖 Updated build preview is available at: Build log: https://circleci.com/gh/ocpdocs-previewbot/openshift-docs/28978 |
. Build your catalog as an image. | ||
. Publish your catalog image. | ||
|
||
For more information, see "Managing catalogs for OLM v1". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
xref
to content to be added after #63086 merges.
|Technology Preview | ||
|
||
|Node Observability Operator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing "Node Observability Operator" from the "Operator lifecycle and development Technology Preview tracker" because it is a duplicate here and is already represented (and is a better fit) over in the "Scalability and performance Technology Preview features" section.
|Technology Preview | ||
|Technology Preview | ||
|Technology Preview | ||
|
||
|Multi-cluster Engine Operator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure why "Multi-cluster Engine Operator" is here in the "Operator lifecycle and development Technology Preview tracker", so I moved it down to the "Architecture Technology Preview features" section since it seemed like it is related to hosted control planes. But I will follow up with the related tech writer to confirm that before merge.
/label peer-review-in-progress |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a nit and a suggestion, otherwise looks good!
/remove-label peer-review-needed /label peer-review-done |
646236d
to
1dc8661
Compare
a782f64
to
7744d10
Compare
//Next-gen (OCP 4.13+) Operator Lifecycle Manager, aka "v1" | ||
:olmv1: OLM 1.0 | ||
:olmv1-first: Operator Lifecycle Manager (OLM) 1.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am borrowing this from the unmerged main
PR https://github.com/openshift/openshift-docs/pull/65963/files. Whichever merges first, this should come out in the rebase-wash.
Looking for another round of peer review since this has had significant additions/changes since the last one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! Generally LGTM, left some comments below
* The `Catalog` API, provided by the new Catalogd component, serves as the foundation for {olmv1}, unpacking catalogs for on-cluster clients so that users can discover installable content, such as Operators and Kubernetes extensions. This provides increased visibility into all available Operator bundle versions, including their details, channels, and update edges. | ||
-- | ||
+ | ||
For more information, see _Operator Controller_ and _Catalogd_. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean to add xrefs here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, yea, mentioned above in #63605 (comment).
|Technology Preview | ||
|Technology Preview | ||
|Technology Preview | ||
|
||
|RukPak | ||
|Not Available | ||
|Java-based Operator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, the Java-based Operator
belongs to the operator-sdk
, not OLM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have this section/table titled as "Operator lifecycle and development Technology Preview features", where "Operator lifecyce" is supposed to suggest "OLM", and "[Operator] development" is supposed to suggest "OSDK". So basically we're treating this table as any features related to the fuller Operator Framework.
|Technology Preview | ||
|Technology Preview | ||
|
||
|Platform Operators | ||
|Hybrid Helm Operator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the Hybrid Helm Operator
belongs to the Operator-SDK
, not OLM.
{olmv1} simplifies Operator management through two key APIs: | ||
+ | ||
-- | ||
* The `Operator` API, provided by the new Operator Controller component, streamlines management of installed Operators by consolidating user-facing APIs into a single object. This empowers administrators and SREs to automate processes and define desired states by using GitOps principles. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, OLM has the Operator
kind before, which is from the CRD operators.operators.coreos.com
. Here is the new Operator
kind from CRD: operators.operators.operatorframework.io
. Both of them use the operator
strings for now.
See the discussion on Slack: https://redhat-internal.slack.com/archives/GHMALGJV6/p1689573773633059 or the https://issues.redhat.com/browse/OCPBUGS-22094
MacBook-Pro:~ jianzhang$ oc get operators.operators.operatorframework.io
NAME AGE
quay-example 4h10m
MacBook-Pro:~ jianzhang$ oc get operators.operators.coreos.com
NAME AGE
cluster-logging.openshift-logging 7h13m
elasticsearch-operator.openshift-operators-redhat 7h13m
loki-operator.openshift-operators-redhat 7h13m
oadp-operator.e2e-test-olm-a-fwobi02w-gsc8h 3h42m
So, to avoid confusion, here I'd suggest using the operators.operators.operatorframework.io
instead of operator
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point! I had created this olmv1-operator-api-group.adoc [NOTE]
snippet in another WIP PR, which talks about that difference, so I'll re-use that here as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well... unfortunately I have discovered you can't use include
statements (e.g., for a snippet) within footnotes, and adding the big [NOTE]
box in-line with the description list and bullets is pretty unsightly. I think I will just change "The Operator
API..." in that first bullet to "A new Operator
API..." and then let the linked-to "see Operator Controller" section (which will have the aforementioned snippet/note in it, after the related PR merges) do the explaining on this matter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://issues.redhat.com/browse/OSDOCS-6727
4.14
Preview: