https://issues.redhat.com/browse/ACM-15420 #7277
Conversation
| ---- | ||
| <1> Define the global settings for all managed clusters that have the observability add-on enabled. | ||
| <2> Used to indicate if the observability add-on is enabled to push metrics to hub cluster server. |
There was a problem hiding this comment.
If I remember correctly we aren't supposed to use callouts for additional information, they are only for variable replacements.
There was a problem hiding this comment.
@oafischer The additional information here is used to explain why the parameters are used. Since last release, I have used callouts as a solution to remove hashtags out of YAMLs.
There was a problem hiding this comment.
I'm OK with the suggestions you provide further down but we might need to bring this up in a meeting since I've been tasked with removing callouts that aren't about replacing variables in the past. Thanks for finding a compromise in the meantime. I'll approve after merging the suggestions.
There was a problem hiding this comment.
@oafischer ok cool, we can discuss in the team channel before I merge.
There was a problem hiding this comment.
This is I think not something we need to stress over, as I see teams use these callouts for a number of things now that I look at it. I don't agree with overusage, or even some of the writing here--or using two at one time for the same line, but see that they are used here by the telco/ocp writer:
There was a problem hiding this comment.
Maybe when we first started using them, because we didn't before, we had guidance to only use them for variables but I lean towards using them to replace any #comments-that-clutter-the-code.
There was a problem hiding this comment.
See here where the same product doc isn't clean and the code is cluttered with comments:
There was a problem hiding this comment.
But I will say that since you have punctuation, these need to be full sentences.
Used to indicate if the observability add-on is enabled to push metrics to hub cluster server. (not complete)
Also, we agreed that unless in code, Observability is proper. You can do either way here. :-)
There was a problem hiding this comment.
@swopebe thanks for your comments and examples. I have updated the file with complete sentence and capitalized "observability" where needed. Awaiting review from @saswatamcode
Co-authored-by: Mikela Jackson <[email protected]>
Co-authored-by: Mikela Jackson <[email protected]>
Co-authored-by: Mikela Jackson <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dockerymick, oafischer The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
New changes are detected. LGTM label has been removed. |
Updating the capitalization for Observability and replaced ROSA reference with the conref.
| observabilityAddonSpec: <1> | ||
| enableMetrics: false <2> | ||
| workers: <3> | ||
| ---- | ||
| <1> Use the `observabilityAddonSpec` parameter to define the global settings for all managed clusters that have the Observability add-on enabled. | ||
| <2> Use the `enableMetrics` parameter to indicate that the Observability add-on is enabled to push metrics to hub cluster server. | ||
| <3> Use the `workers` parameter to list worker nodes into the metric collector process to shard federate requests made to Prometheus on your hub cluster. Then the metric collector sends sperate remote-write requests to Thanos on your hub cluster. |
There was a problem hiding this comment.
@saswatamcode when you have a chance, will you review this part of the PR please?
No description provided.