Design proposal to reroute alerts by org id

[samanthajayasinghe]

What type of PR is this?

documentation

What this PR does / Why we need it?

Design proposal to reroute alerts by org id

Special notes for your reviewer

Test Coverage

Guidelines for CAD investigations

• New investgations should be accompanied by unit tests and/or step-by-step manual tests in the investigation README.
• Actioning investigations should be locally tested in staging, and E2E testing is desired. See README for more info on investigation graduation process.

Test coverage checks

• [ ] Added tests
• [ ] Created jira card to add unit test
• [ ] This PR may not need unit tests

Pre-checks (if applicable)

• [ ] Ran unit tests locally
• [ ] Validated the changes in a cluster
• [ ] Included documentation changes with PR

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: samanthajayasinghe Once this PR has been reviewed and has the lgtm label, please assign nikokolas3270 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[bergmannf]

Thanks for the contribution to CAD - I can see you put a lot of effort into this and it looks well structured, but I have a few fundamental questions:

• AFAIK there are no 'support-tiers' so I don't see an immediate need for this (as there is no code this probably also is more of an idea document?)
• As there is no concrete code changes (apart from the examples in the markdown) I wonder if the actual CAD repository is the right place to put a document of ideas? I would like to keep this somewhere so not to loose all the great effort put it, but I feel the CAD repository should be the source of truth for what we settled on not what we are considering right now.

Maybe we can have a quick sync about where this design originates and in which timeframe we feel we need this and then get to a decision - in the end I like the idea of documenting what we settle on a lot but I would like to get rid of the 'alternatives' in this doc and only keep the one we will implement with reasoning as to why.

[joshbranham]

FYI @rafael-azevedo is working on the implementation of this all in https://github.com/openshift/configuration-anomaly-detection/pull/629, based on the ticket I filed, so we may not need this doc anymore.