Description:
As a follow on to #3242 and #3254 we want to get a more robust solution implemented to template specific receiver groups email addresses for Alertmanager. Currently, when deploying PLG, the deployer must have a specific environment variable(s) set on their machine to allow for the correct templating of the receiver configs in the alertmanager.yml. This is extremely error prone. Instead we would like to investigate a more robust solution to defining email receivers such that they are accessible to the appropriate audience and are not published in our public gitrepo.
Acceptance Criteria:Create a list of functional outcomes that must be achieved to complete this issue
[ ] Robust solution identified
[ ] Tech memo outlined?
[ ] Testing Checklist has been run and all tests pass
[ ] README is updated, if necessary
Tasks:Create a list of granular, specific work items that must be completed to deliver the desired outcomes of this issue
[ ] Investigate solutions
[ ] Write tech memo?
[ ] Run Testing Checklist and confirm all tests pass
Notes:Add additional useful information, such as related issues and functionality that isn't covered by this specific issue, and other considerations that will be helpful for anyone reading this
distribution list for developers//alex? service acct?
Note 2
Note 3
Supporting Documentation:Please include any relevant log snippets/files/screen shots
Doc 1
Doc 2
Open Questions:Please include any questions or decisions that must be made before beginning work or to confidently call this issue complete
Description: As a follow on to #3242 and #3254 we want to get a more robust solution implemented to template specific receiver groups email addresses for Alertmanager. Currently, when deploying PLG, the deployer must have a specific environment variable(s) set on their machine to allow for the correct templating of the receiver configs in the
alertmanager.yml
. This is extremely error prone. Instead we would like to investigate a more robust solution to defining email receivers such that they are accessible to the appropriate audience and are not published in our public gitrepo.Acceptance Criteria: Create a list of functional outcomes that must be achieved to complete this issue
Tasks: Create a list of granular, specific work items that must be completed to deliver the desired outcomes of this issue
Notes: Add additional useful information, such as related issues and functionality that isn't covered by this specific issue, and other considerations that will be helpful for anyone reading this
Supporting Documentation: Please include any relevant log snippets/files/screen shots
Open Questions: Please include any questions or decisions that must be made before beginning work or to confidently call this issue complete