[config] Add squad intermediate abstraction

[diraol]

what

Change a bit how the setup module works to enable multiple squads definitions, with each one having its own directory. To allow this we had to change a bit the "main" code to enable the merge of multiple different yaml "keys" together.

why

This improves usability by enabling multiple squads in its own directory/file, avoiding huge yaml files.

[Benbentwo]

I'm a little confused by this PR, hoping I can get some clarification. I understand the point is to breakup your config into multiple smaller files. Then merge them in together as a definition of a squad for this to then render.

Couple questions:

1. what is a squad relative to an Opsgenie Team or other Opsgenie Terms?
2. Did you try wrapping this module in a component that handles the file merge as it's own logic? This sounds similar to what we do for datadog monitors. This repository is the module (config) which in the datadog example is the datadog-monitor submodule. then you could have other modules that read and merge yaml config - which we have some modules pre-built.

My concern is adding implementation specific details to this module. we usually try to save opinionated implementation specifics for the component itself - which is opsgenie-team for this module

[diraol]

I'm a little confused by this PR, hoping I can get some clarification. I understand the point is to breakup your config into multiple smaller files. Then merge them in together as a definition of a squad for this to then render.

Couple questions:

1. what is a squad relative to an Opsgenie Team or other Opsgenie Terms?
2. Did you try wrapping this module in a component that handles the file merge as it's own logic? This sounds similar to what we do for datadog monitors. This repository is the module (config) which in the datadog example is the datadog-monitor submodule. then you could have other modules that read and merge yaml config - which we have some modules pre-built.

My concern is adding implementation specific details to this module. we usually try to save opinionated implementation specifics for the component itself - which is opsgenie-team for this module

well......
I didn't know about the opsgenie-team module.... I guess I didn't need this module then, and should have gone straight forward to opsgenie-team.... 😿

For my context a squad currently is similar to an opsgenie team.

Nevertheless, breaking into smaller files to be merged may still be useful. If you have too many configs those yaml files can grow substantially and their maintenance can be a bit cumbersome.
But I really don't know where to go to from here.

[Benbentwo]

I didn't know about the opsgenie-team module.... I guess I didn't need this module then, and should have gone straight forward to opsgenie-team.... 😿

I'd try looking into that module. I'm not sure on your setup - but that component uses context (namespace tenant stage variables) and assumes you are using datadog as well. it might be what you need.

For my context a squad currently is similar to an opsgenie team.

In that case I would suggest just using an opsgenie team. wrap this module in it's own terraform module (this repo then becomes the child module). you can use a for_each - this will make your component a factory of opsgenie teams which we actually recommend against if you are using atmos.

Atmos abstracts away the factory part so that each component (directory in your infra repo with terraform) creates 1 collection of resources well (not many - a factory) then uses stacks and imports to declare many instances of that component. might be helpful if you're not already using atmos.

Nevertheless, breaking into smaller files to be merged may still be useful. If you have too many configs those yaml files can grow substantially and their maintenance can be a bit cumbersome.
But I really don't know where to go to from here.

While I agree splitting configs into smaller bite sized is better - I think adding new custom terms and paths will add to confusion for this child module, seems like it would be a better fit in a wrapper module or component. I am going to close this PR as I do not think this child module is a good spot for adding new terms that are not directly defined by opsgenie..

But I really don't know where to go to from here.

Can you explain (either here or slack) what problems or decisions you have to make? perhaps we can come up with something together