Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decision Module location metrics #2040

Open
npalm opened this issue May 9, 2022 · 3 comments
Open

Decision Module location metrics #2040

npalm opened this issue May 9, 2022 · 3 comments
Assignees
Labels
metrics Metrics, Monitoring and Alerting stale:exempt

Comments

@npalm
Copy link
Member

npalm commented May 9, 2022

We are exploring the options to add features related to Monitoring and Alerting to tthe module, see #2025 and project.

We are aming to provide an AWS native soltuion that will be a complete opt-in. At this moment we have not a clear picture how to complete feature in the end will look like. But most likely it will consist of one or muliple terraform modules. We also have seen the comlexity of the repository have grown over the time. This raises the question should we start form a new repository of include the features in this repository.

Pro's mono repo:

  • One single release, no extra work for maintainers and users to ensure the right version of releases are mathcing.
  • Most likely several parts of metrics are in close connected to logic available in the current module.

Con's mono repo:

  • Metrics will be an optional feature, with a single repository change in metrics create a runner release as well. Breaking cahnges in one of both modules will impact release strategy on both.
  • Complexity of repo
  • From a metrics module point of view, it is always connected to the runners module. Does not make sense to have it seprate.
@npalm npalm created this issue from a note in Monitoring and Alerting (In progress) May 9, 2022
@npalm npalm added the metrics Metrics, Monitoring and Alerting label May 9, 2022
@Brend-Smits
Copy link
Member

My preference would be to keep it in this repository seeing as it has direct (perhaps on internal) dependencies on the runners module and our current core-maintainer team is already small enough. Spreading it across multiple repositories might just increase workflow unnecessarily due to maintaining releases and different repositories and communities.

@ScottGuymer
Copy link
Member

I think we need to try and keep the module logically separate from each other so we dont have to deploy both at once. But I agree that it can live in this repo (at least until we find a reason for it not to)

@github-actions
Copy link
Contributor

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the Stale label Jun 17, 2022
Monitoring and Alerting automation moved this from In progress to Done Jun 27, 2022
@npalm npalm reopened this Jul 11, 2022
Monitoring and Alerting automation moved this from Done to In progress Jul 11, 2022
@npalm npalm added stale:exempt and removed Stale labels Jul 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
metrics Metrics, Monitoring and Alerting stale:exempt
Projects
Development

No branches or pull requests

4 participants