Delete flag for configuration

[kristofre]

Similar to the skipDeployment flag, it would be great to have a delete flag that you can use to delete config.

This would allow us to make deletion project-specific, and by using environment-specific configuration, you can choose to delete it from specific environments:

config:
    - app-one: "application.json"
  
app-one.staging:
    - name: "app-one"
    - uemPercentage: "75"

app-one.production:
    - name: "app-one"
    - uemPercentage: "75"
    - delete: "true"

[tatomir146]

I like this idea, but we should anyways still support delete.yaml file, because to delete existing configuration, you would first need to import this to the monaco.

Btw this discussion duplicates #201

[robertjahn]

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

[kristofre]

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

I think the use case is the opposite? I want to be able to label something from within the yaml to be deleted and you want to avoid deletion?

[robertjahn]

My use case (also in Slack) is that I do demos --- I want to setup the config via monaco, do my demo, then run monaco to delete everything. when the delete.yaml file was there -- config got added and then deleted -- so I had to hack it by renaming delete.yml when I did not not it run -- then rename if back to delete.yaml and run monaco to delete everything. So not sure if any current solution (flags, optional delete file) solves this for me. and if I make two projects (one with the delete and one without -- then I have to duplicate all the config files -- which makes no sense either)

[radu-stefan-dt]

When working with multi-project setups and especially dynamically generated content, I noticed this could be a powerful feature to have.

Currently I see two options:

1. As Kristof mentions above, the "delete" flag within the properties of a config instance.
2. The longer reference within the delete.yaml to allow for project references as well. For example:

delete:
  - "proj1/slo/My Slo"

Since the delete.yaml is in root folder anyway, it should be easy to map projects from there. This would allow running projects separately and give more control to deletions. In the example above I can ensure I'm only deleting "My Slo" when I'm running project "proj1".

[robertjahn]

I still believe having the option to just delete something without making it would be great. I would like to have a delete.yaml file with the config types and names of the config item defined as we have it now....and then just say monaco delete -f delete.yaml independent of creating the config AND to delete things that are not defined within the monaco project subfolders.

[robertjahn]

Perhaps two flags --delete-only and --skip-delete as the start. That would go along way to supporting new use cases

[radu-stefan-dt]

I am not disagreeing with you.

Logically I think it makes more sense to have delete as a separate command. However it does require more implementation work as a separate command (first makings GETs to see if IDs exist for those configs, then running the DELETEs to remove them).
Currently it's cutting some corners because the create/update as first step ensures we already have the IDs when we get to the delete step.

[robertjahn]

The "--skip-delete" one might be a place to start. I don't know the code if you do the create/update then the delete, just add a check to say "if --skip-delete then don't do the delete"

[tatomir146]

So we are talking about 2 things here:

• improving current delete.yaml so it's possible to delete configs only for specific project
• introducing new parameter so config could also be deleted directly in yaml (project and config specific)

IMO the way to go here would be introducing new delete command. With monaco 2.0 we will anyways support: deploy, download, convert and it would also make sense to add delete. This way, user could decide when and what to delete.
monaco delete [command options] deployment-manifest
It would also make sense to support verbose (v) and environment (e) options.

Additionally, we would also introduce new delete parameter in config object.

[UnseenWizzard]

@kristofre , @radu-stefan-dt , @robertjahn we've just discussed this internally among the maintainers and we'd like to do the following with monaco 2.0:

• monaco deploy not longer deletes anything
• monaco delete [-e SPECIFIC_ENV] MANIFEST_FILE DELETE_FILE will delete the configs listed in DELETE_FILE from the environments in the MANIFEST_FILE (or a specific one of them)

The format of delete.yaml will stay unchanged at this time in its api/name format.

From our point of view this covers both our desire to simplify monaco both in terms of code and usability, and the requirements you have.

Generally this means you will have to write your delete.yaml as before, but can decide when to actually delete things.
If you have a strong need for deleting projects we could introduce a way to generate a delete.yaml from a given project at a later point in time.

Please let me know what you think of this solution :)

[UnseenWizzard]

fyi @tatomir146 , @patrickpichler , @didiladi , @LaSacre

[radu-stefan-dt]

Is delete.yaml filename going to be customizable?
Because if not, when I'm automating deletes as part of multiple environments, I have to carefully orchestrate my delete activity to protect against collisions:

• write delete.yaml for env 1, run delete for env 1
• update delete.yaml for env2, run on env 2
• etc.

Or am I misunderstanding it?

Because in the content of delete.yaml I cannot say api/name-X from env 1 but not env 2. And then as part of the command delete.yaml is just one file where again there's opportunity for collision (as opposed to, for example delete-env1.yaml, delete-env2.yaml etc. where I can do all my writing at once). It is a bit of a more dynamic/automated approach to generating/deleting config that requires this separation, but it happens I'm using it for such a setup.

[UnseenWizzard]

Ah sorry, yes both manifest and delete files should just be things you point the command to.
So you will be able to have as many delete files as needed.

I've updated my sample :)

[radu-stefan-dt]

Thanks Nico. That meets my objective!

[ghost]

I had the same requirement for demo participants to quickly delete created config so I wrote this script which isn't battle-hardened in any way (or even error checking) but does the job for my immediate purposes.

https://github.com/Dynatrace-Adam-Gardner/monaco-delete-file-generator/tree/main

python3 generate-delete-file.py