Feature Overview

Some customers want to also set their own custom configuration in the configuration of a spoke's alertmanager

Goals

Having two management systems ( gitops and rhacm ) to manage the alert-manager configuration of spoke clusters creates issues and conflicts. To work around that, I would like to propose to adopt a system where rhacm can be set to add additional settings and configuration to what it would apply to alert-manager on a spoke.

Requirements

This Section: A list of specific needs or objectives that a Feature must
deliver to satisfy the Feature.. Some requirements will be flagged as MVP.
If an MVP gets shifted, the feature shifts. If a non MVP requirement slips,
it does not shift the feature.

(Optional) Use Cases

For the case I am raising this feature for, the customer wishes to keep using gitops to enforce the configuration, but got hit with a conflict with RHACM that lead to changes betwee the two. Disabling the application of alertmanager changes through rhacm did not fix it entirely due to the need to rollback (though that can likely be worked around)

Questions to answer

How can we make the management of alertmanager configuration between gitops and rhacm easier and raise the interractivity between the two systems in regards to custom alertmanager configuration?

Out of Scope

• …

Background, and strategic fit

This Section: What does the person writing code, testing, documenting
need to know? What context can be provided to frame this feature?

Assumptions

Customer Considerations

Customers, while being offered to forward alerts from RHACM, preffer to forward them from the spoke clusters instead (this is creating less points of failure for alert forwarding and feature levels in the alertmanager implementation of spoke clusters can be higher than what RHACM can offer).

Documentation Considerations

It is not a bad idea to add to an anex what kind of forward rules should be set to forward alerts to the RHACM instance. This would allow for more flexibility when other management systems for the application of configuration would be used (like gitops here)

Questions to be addressed:

• What educational or reference material (docs) is required to support this
  product feature? For users/admins? Other functions (security officers, etc)?
• Does this feature have a doc impact?
  It will likely have a need for additional documentation over how to customize the alertmanager configuration from RHACM
• New Content, Updates to existing content, Release Note, or No Doc Impact
• If unsure and no Technical Writer is available, please contact Content
  Strategy.
• What concepts do customers need to understand to be successful in
  [action]?
• How do we expect customers will use the feature? For what purpose(s)?
  They are likely going to use it to configure alertmanager on spoke cluster through RHACM rather than forcing them to disable it and self configure it.
• What reference material might a customer want/need to complete [action]?
  example configuration, explanation of what to configure and where.
• Is there source material that can be used as reference for the Technical
  Writer in writing the content? If yes, please link if available.
• What is the doc impact (New Content, Updates to existing content, or
  Release Note)?
  update and extention of exisitng content.