Skip to content

[WIP] OBSDOCS-71: [POC] Observability operators upgrade resource #79103

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.

Sign up for GitHub

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

Closed
wants to merge 1 commit into from
Closed

[WIP] OBSDOCS-71: [POC] Observability operators upgrade resource #79103

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions modules/obs-support-version-matrix-for-observability-components.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
// Module included in the following assemblies:
//
// * observability/index.adoc

:_mod-docs-content-type: REFERENCE
[id="obs-support-version-matrix-for-observability-components_{context}"]
= Support version matrix for {ObservabilityShortName} components

The following matrix contains information about supported versions of {ObservabilityShortName} components for {product-title} 4.12 and later releases.

[NOTE]
====
The monitoring component is deployed by default in every {product-title} installation. Therefore, its version corresponds with the versions of {product-title}.
====

.{product-title} and component versions
|===
|{product-title} |{logging-uc} |Distributed tracing (Tempo) |Distributed tracing (Jaeger) |{OTELName} |Network Observability |{PM-shortname-c}
Copy link
Contributor

@max-cx max-cx Jul 23, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eromanova97, the currently added versions for |Distributed tracing (Tempo) |Distributed tracing (Jaeger) |{OTELName} are for upstream projects, so we'd better not mention them in this table. These three components share the same downstream product version (latest is 3.2) for all three of them. All three have the same supported OCP versions: 4.12, 4.13, 4.14, 4.15, 4.16.

🙂 BTW, I wish the Observability components were given rows (which will make each component name appear on one line for better readability), rather than columns, and that only the latest version were included. In other words, I wish that the OpenShift versions were given columns, which is also easier to arrange on the page because OCP version numbers are shorter than component names.

Copy link
Contributor Author

@eromanova97 eromanova97 Jul 24, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @max-cx thank you for the explanation! I am including all the supported versions instead of just latest, because the main reason we want to add this table is for users to have reference table when they need to update from one OCP version to another, so it would be good for them to know when they need to update their Observability components and when not.

For example, let's say they have Logging version 5.8 installed and they are updating from OCP 4.14 to 4.15. Thanks to this table, they would know that they do not have to update the Logging component, because 5.8 is supported in both 4.14 and 4.15. If we just include the latest versions, they would see only 5.9 for OCP 4.15, which would not tell them what they need to know, that is, 5.8 is supported too.

I hope that explains the decision to include all the supported versions 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding the rows vs columns, I thought to include it like this because we will need to update the table with each OCP release, and it is easier to add a new row instead of column 😃 but otherwise, I have no problem including it as you suggested, I will try and see what looks better once i update the table again 👍

Also, based on the previous comment, could you please let me know all the supported downstream product versions for OCP 4.12+? Based on the release notes I suppose it is 2.0+ for all OCP 4.12+ versions?

Copy link
Contributor Author

@eromanova97 eromanova97 Jul 24, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, with this information that it is for users when they need to update their cluster, will they be able to figure out which version to choose when they are installing the given operator (e.g. Tempo)? What I mean by that: is it clear for the users, if they want, e.g. 3.2 latest version , what upstream versions are compatible? Because when I tried to install the operators from OperatorHub, I could only see those upstream versions, not the downstream (2.0, 3.2, etc.) versions)

Copy link
Contributor

@max-cx max-cx Aug 12, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eromanova97, 🙂 I thought about it for a while, and here are some things that came to mind:

  1. I just noticed that the heading, abstract, and table title refer to "component versions", however the table cells contain "downstream/RH operator versions", which is not the same.

  2. As far as I can see, to include all released operator versions means that we are also presenting information about operator versions that are outdated and no longer supported. I'd assume that, if we are presenting this information, we intend to help readers, but making readers look at this table and based on it install an operator version that is no longer supported or is soon to become unsupported as well as is outdated because there are newer operator versions, will backfire for some customers. For example, versions 5.5, 5.6, 5.7, 5.8, and 5.9 are listed for the Logging operator, and of these, versions 5.5, 5.6, 5.7, and 5.8 have their full support already ended. The problem with looking at this table is it doesn't show the end of support dates for each of the listed operator versions, and there's more than just one end of support date for each. But even among the currently supported versions, AFAIK, general guidance for software is to install the latest version, due to a number of reasons including bug fixes and CVEs.

  3. If you haven't done so yet, I suggest that you have a look at the data in the following two pages to get a better idea of the user story and info that this table seeks to present:
    https://access.redhat.com/support/policy/updates/openshift/
    https://access.redhat.com/support/policy/updates/openshift_operators

  4. TBH, every time I see a table, I wonder if it's the best way to organize the information it contains. The reason for this caution is my personal experience: On my previous product, I had to update a support table in the release notes, and every now and then there'd be feedback that something was not presented correctly. In the end, I was able to put all that information into a short single sentence with a few bullet points, which was ironically easier to digest, and so I got rid of the table. The reason I'm raising this point is the fact that (if we ignore the fact that Power Monitoring was released for 4.14+), the only other Observability component with operator versions that differ across the currently supported OCP versions is Logging. And for all the other Observability components, the version are the same for all the currently supported OCP versions. In other words, Distributed tracing (Tempo), Distributed tracing (Jaeger), Red Hat build of OpenTelemetry, and Network Observability, have exactly the same information copied and pasted multiple times in 5 cells each. 😅 This seems like a lot of fluff for readers to look at and for us to maintain in the docs.

😃 Good luck with whichever way you decide to proceed with this PR.


|4.16 |5.8, 5.9 |0.1.0, 0.3.1, 0.6.0, 0.8.0, 0.10.0 |1.30.2, 1.34.1, 1.42.0, 1.47.1, 1.51.0, 1.53.0, 1.57.0 |0.56.0, 0.60.0, 0.74.0, 0.81.1, 0.89.0, 0.93.0, 0.100.1, 0.102.0 |1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.6.0 |0.1, 0.2

|4.15 |5.8, 5.9 |0.1.0, 0.3.1, 0.6.0, 0.8.0, 0.10.0 |1.30.2, 1.34.1, 1.42.0, 1.47.1, 1.51.0, 1.53.0, 1.57.0 |0.56.0, 0.60.0, 0.74.0, 0.81.1, 0.89.0, 0.93.0, 0.100.1, 0.102.0 |1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.6.0 |0.1, 0.2

|4.14 |5.7, 5.8, 5.9 |0.1.0, 0.3.1, 0.6.0, 0.8.0, 0.10.0 |1.30.2, 1.34.1, 1.42.0, 1.47.1, 1.51.0, 1.53.0, 1.57.0 |0.56.0, 0.60.0, 0.74.0, 0.81.1, 0.89.0, 0.93.0, 0.100.1, 0.102.0 |1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.6.0 |0.1, 0.2

|4.13 |5.6, 5.7, 5.8, 5.9 |0.1.0, 0.3.1, 0.6.0, 0.8.0, 0.10.0 |1.30.2, 1.34.1, 1.42.0, 1.47.1, 1.51.0, 1.53.0, 1.57.0 |0.56.0, 0.60.0, 0.74.0, 0.81.1, 0.89.0, 0.93.0, 0.100.1, 0.102.0 |1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.6.0 |N/A

|4.12 |5.5, 5.6, 5.7, 5.8 |0.1.0, 0.3.1, 0.6.0, 0.8.0, 0.10.0 |1.30.2, 1.34.1, 1.42.0, 1.47.1, 1.51.0, 1.53.0, 1.57. |0.56.0, 0.60.0, 0.74.0, 0.81.1, 0.89.0, 0.93.0, 0.100.1, 0.102.0 |1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.6.0 |N/A
|===
4 changes: 4 additions & 0 deletions observability/index.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,6 +26,10 @@ endif::openshift-dedicated,openshift-rosa[]

{ObservabilityLongName} connects open-source observability tools and technologies to create a unified {ObservabilityShortName} solution. The components of {ObservabilityLongName} work together to help you collect, store, deliver, analyze, and visualize data.

ifndef::openshift-dedicated,openshift-rosa[]
include::modules/obs-support-version-matrix-for-observability-components.adoc[leveloffset=+1]
endif::openshift-dedicated,openshift-rosa[]

[id="monitoring-overview-index"]
== Monitoring
Monitor the in-cluster health and performance of your applications running on {product-title} with metrics and customized alerts for CPU and memory usage, network connectivity, and other resource usage. Monitoring stack components are deployed and managed by the {cmo-full}.
Expand Down