[WIP] OBSDOCS-71: [POC] Observability operators upgrade resource #79103
Conversation
|
@eromanova97: This pull request references OBSDOCS-71 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.17.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-robot
added
the
jira/valid-reference
openshift-ci
bot
added
do-not-merge/work-in-progress
|
@eromanova97: This pull request references OBSDOCS-71 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.17.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. |
|
@eromanova97: all tests passed! 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-sigs/prow repository. I understand the commands that are listed here. |
|
|
||
| .{product-title} and component versions | ||
| |=== | ||
| |{product-title} |{logging-uc} |Distributed tracing (Tempo) |Distributed tracing (Jaeger) |{OTELName} |Network Observability |{PM-shortname-c} |
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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 🙂
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
@eromanova97, 🙂 I thought about it for a while, and here are some things that came to mind:
-
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.
-
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.
-
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 -
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.
5 participants
Version(s):
enterprise-4.12and laterIssue: OBSDOCS-71
Link to docs preview: https://79103--ocpdocs-pr.netlify.app/openshift-enterprise/latest/observability/index.html#obs-support-version-matrix-for-observability-components_observability-overview
QE review:
Additional information: