Monaco automatically deletes configurations in Dynatrace when removed from Monaco project

[kristofre]

I believe this ties into #16 as well, but wanted to make a separate feature request for it.

Monaco should have a mode where it is running as "single source of truth" for configuration, in a true GitOps model.
This means that when a configuration is removed from a centralised Monaco repo, upon the next Monaco run this config should also be removed from Dynatrace.

Since Monaco does not keep a state, one solution could be that Monaco retrieves a list of all configurations (e.g. Applications). After a successful run of applying configuration, it does a diff between what the desired state is (in Monaco config repo) and the current state (in Dynatrace). What is extra in Dynatrace should be removed.

This should probably not be the defacto standard operating mode of Monaco, but it should be an option controlled either by a flag or an environment variable.

[163a]

My opinion on this is that you would need to implement this in a way that Monaco becomes aware of an centralised repository to compare those diffs.
The other factor is having Monaco "automatically" include those manually added configurations, so that there is a synchronisation. Maybe this is better suited to another tool?

[julieallard]

That is exactly what we need. This would allow Monaco to clean up any manual changes in the UI because people are not supposed to make manual changes. That would allow us to enforce that everyone makes config changes via pull requests.

[tatomir146]

I think we already had discussion about this some time ago but storing the state locally would complicate the things a bit. To properly implement this, support in product would also be needed. But, there is actually a way of making this work:

• store all configuration in repo (monaco already overwrites everything)
• remove permission from users so they can't do any unwanted changes
• (optionally) implement 4 eyes principle on adding config to the repo

[kristofre]

Agree that a state is currently not the best and will complicate things a lot.

A feature like this is still handy when it comes to simplifying the deletion process. At the moment you would need to delete the config from the repo and then also manually add the to-be deleted config to the delete.yaml.

Being able to just take the repo as the main source of config, would vastly simplify handling the deletion of config.

[ARZ-SagA]

i like this idea

the terraform provider is already working in this mode
https://github.com/dynatrace-oss/terraform-provider-dynatrace

[UnseenWizzard]

Personal (but strong) opinion: I do not want monaco to keep state.
That is a huge change from it's currently state and (mostly) content agnostic design, and importantly an overlap with tools that are designed for such operations, like terraform.

As the need exists, I would prefer us to solve it by focusing on:

• Making monaco's wrappers of the DT API a usable abstraction library
• Adding a utility to convert a monaco repo to Terraform DSL
• Contribute to the terraform provider project

[robertjahn]

I think having a simple switch like monaco deploy --skip-delete and monaco deploy --skip-delete --project XX would meet my needs

[kristofre]

@UnseenWizzard as mentioned above, a state is not needed. Since Monaco already gets all the configs anyway as part of normal operation, we can see what the delta is between local config and remote config. All the ones that are not present in monaco but are present in Dynatrace should be deleted from Dynatrace. So if I have 10 management zones in DT but only 8 of them are defined in Monaco I will delete the other 2. This will help keeping config in DT a lot cleaner.

As said this should not be the default behaviour, but a mode we could support.

[sfgdpm]

This feature is something that we would really like to see added, as well.

One way I think this could be implemented, without impacting manually managed configuration, would be to have a unique tag added to each resource in a particular Monaco project. If you enable auto purge, you could then scope the Monaco resource gathering runs based upon that tag and delete anything that isn't currently managed by the project.

This was the strategy we took when implementing resource management via Puppet (before Monaco was available) and it worked as expected, though we only scoped that work to the four resources we needed for that use case.