Describe the bug
Configuration type folder names are case sensitive. No configuration will be applied if folders are not lowercase.

But, no error is shown if folders are not lowercase.

How to reproduce
Steps to reproduce the behavior:
Create a folder called auto-tag with valid config. This will work:

monaco.exe --environments=environments.yaml
2020-11-20 08:57:32 INFO  Dynatrace Monitoring as Code v1.0.0
2020-11-20 08:57:32 INFO  Executing projects in this order:
2020-11-20 08:57:32 INFO        1: projects\baseconfig\auto-tag (1 configs)
2020-11-20 08:57:32 INFO  Processing environment my_environment...
2020-11-20 08:57:32 INFO        Processing project projects\baseconfig\auto-tag...
2020-11-20 08:57:32 INFO  Deployment finished without errors

Delete the tag rule and rename auto-tag to Auto-Tag. Re-run monaco:

monaco.exe --environments=environments.yaml
2020-11-20 08:57:32 INFO  Dynatrace Monitoring as Code v1.0.0
2020-11-20 08:57:32 INFO  Executing projects in this order:
2020-11-20 08:57:32 INFO        1: projects\baseconfig\Auto-Tag (0 configs)
2020-11-20 08:57:32 INFO  Processing environment my_environment...
2020-11-20 08:57:32 INFO        Processing project projects\baseconfig\Auto-Tag...
2020-11-20 08:57:32 INFO  Deployment finished without errors

This time, no tag rule is created.

Expected behavior
Either accept case insensitive foldernames or print a warning for invalid folder names.

I found already a couple of times that when executing the synthetic set-up the Synthetic locations just stop to work with the unknown location error- Find below the error I've got:

020-11-20T15:28:28.9848035Z 2020-11-20 15:28:28 INFO Dynatrace Monitoring as Code v1.0.0
2020-11-20T15:28:29.0296087Z 2020-11-20 15:28:29 INFO Executing projects in this order:
2020-11-20T15:28:29.0296961Z 2020-11-20 15:28:29 INFO 1: projects\Application (9 configs)
2020-11-20T15:28:29.0297515Z 2020-11-20 15:28:29 INFO Processing environment Germany...
2020-11-20T15:28:29.0297841Z 2020-11-20 15:28:29 INFO Processing project projects\Application...
2020-11-20T15:28:29.8322009Z 2020-11-20 15:28:29 ERROR Deployment to Germany failed with error Failed to upsert DT object GE_APP-123_XXXXX (HTTP 400)!
2020-11-20T15:28:29.8323595Z Response was: {"error":{"code":400,"message":"Unknown location(s): [GEOLOCATION-5760CF2C54BBEE66]"}}, responsible config: projects\Application\synthetic-monitor\synthetic-monitor.json

Currently the Dynatrace Monitoring as Code tool only allows to reference the id/name of created Dynatrace objects

Referencing variables from another yaml configuration is not possible, but would be helpful.
E.g. to reference the names of metrics from a plugin configuration in a dashboard configuration

If using flags without equals "=" there is a bug if specifying project parameter as latest:
command... -p my_project

2020/04/16 11:07:02 Project my_project does not exist!: stat my_project/my_project: no such file or directory

Following works:
command... -p=my_project

The last parameter gets interpreted as configuration root parameter

Extensions are not deleted during clean up TestIntegrationCleanup

Describe the bug
When opening the project with Goland, you see the following error:

Unresolved references due to the variables folder and environmentsFile being defined in file multi_tenant_integration_test.go. Seems like this also inicates another bug, where we create configs for different environments, as we try to clean after running the integration tests. This also leads to the fact, that we try to clean up different configs, as we apply in the integration test run.

How to reproduce
Just start Goland

Expected behavior

• The error is gone
• Cleanup is run for the same environments as the configs are applied to
• We clean up the same configs, as the tests creates

Log output
If applicable, add log snippet to help explain your problem.

Environment (please complete the following information):
All

When help text output is not really helpful, as it doesn't show all possibilities how
to execute monaco.

For example there is no info at all, how to specify which folder the project configurations
are in.

For application detection rules, there is an API which enables a user to define the ordering of application detection rules.

Add support for this API in Dynatrace Monitoring as Code.

There is currently an issue when defining multiple configs in a single yaml with similar names.

E.g. have two configs with one called dashboard and the other dashboard-availability.

dashboard will now add all properties from dashboard-avilability to its properties map.

This causes checks such as HasDependencyOn(Config) to als search for dependencies
on this wrong properties.

The cause for this is in conifg.go line 84:

func filterProperties(id string, properties map[string]map[string]string) map[string]map[string]string {

	result := make(map[string]map[string]string)
	for key, value := range properties {
		if strings.HasPrefix(key, id) {
			result[key] = value
		}
	}
	return result
}

Simply testing for HasPrefix isn't enough here.

The documentation mentions in some places environment-url when in reality this
configuration key is called env-url.

We would like to see a more verbose logging than currently is the case.

It would be interesting to see:

• API call made
• Response code

Given this YAML, the tool fails but it is valid YAML.

config:
  - 1234: "file.json"

1234:
  - name: "My Name"

Discuss whether or not to support this in the tool.

Enhancement request to support for service request naming rules:
/api/config/v1/service/requestNaming

https://www.dynatrace.com/support/help/shortlink/api-request-naming

See: https://www.dynatrace.com/support/help/technology-support/cloud-platforms/kubernetes/installation-and-operation/further-integrations/connect-your-kubernetes-clusters-to-dynatrace/

There is an API for doing that. Add the necessary configs in the infrastructure project in the self-monitoring tooling.

If a property defined in the yaml is a boolean, it feels counter-intuitive to write it as a string like: "true". This already caused confusion for a customer.

The following should be possible:

config:
  - email: "email.json"
email:
  ...
  - enabled: true

Instead of:

config:
  - email: "email.json"
email:
  ...
  - enabled: "true"

Release notes should be generate automatically once new release is created.

It will be great to be able to automate also anomaly detection rules for other items like Infra, DB, applications, etc....

It is quite easy by copy and paste pull create configs which have properties that are not used.

E.g.

dashboard:
  - name: "test"
  - testTicket: "hello"

{
  "name": {{ .name }}
}

When running dry run, it would be nice to point out that testTicket is unused.

Currently we build and test on Linux only, but release Linux, Windows and Mac versions of the tool.

To be more confident in those, we should run at least the integration tests on all platforms to continuously ensure that these releases function.

In trial we've already seen that there are the following issues with this:

• linting check is using a shell script that is not compatible with windows (it does this to get around gofmt not returning error codes on unformated files)
• integration tests running in parallel influence each other, resulting in some tests timing out or failing

Dynatrace provides different APIs for configuration. Those APIs can change or there can be new APIs added. In order to be fault-tolerant and proactive, we should only perform the actions, the target environment supports.

Implement a preflight check for each target environment using the OpenSpecAPI
In case an API doesn't exist yet on this environment, log an information about the unavailable API
If the "not executed API call" is a prerequisite for another configuration, we have to cancel this one as well

If linking extension.name from one to another project, we get following error:

Id 'general/extension/some-id' was not available. Please make sure the reference exists.

There is a problem with checking Ids on extensions. id was not populated with .id (using old plugins API), but after switching to extensions API, now there is a id parameter on successful upload returned from api:

{
    "id": "custom.jmx.my-extension"
}

It may be worth to document the minimum API token requirements needed for creating the new Dynatrace config using this new "as code" tool

As of right now, the cli is not really obvious to use. There are multiple
flags which are required, some which trigger different actions also we
have positional elements.

This ticket was created to kick off a discussion and collect proposals
on how to improve the cli design.

As of right now, all / in the config will be replaced with \ on windows. This
could lead to some strange behaviors, such as replacing / in names.

This is done solely to handle paths on windows, but if you think about it, there
is no need to replace every / in the config, as we read files from disk only once
at the beginning. Afterwards / could always be used to reference other configs.

Apart from using monaco to configure a Dynatrace Environment configuration, it would also be great to have the ability to configure a Dynatrace Managed cluster.

Describe the solution you'd like
The ability to specify a managed cluster and token, and then configure the cluster using monaco

Endpoints that come to mind:

• CRUD of a tenant
• CRUD of Users/Groups
• Cluster configuration itself

Is this a typo? upsert should be insert?

https://github.com/dynatrace-oss/dynatrace-monitoring-as-code/blob/389a293894d51515214afd7887687df1d6ead164/pkg/rest/config_upload.go#L32 and https://github.com/dynatrace-oss/dynatrace-monitoring-as-code/blob/389a293894d51515214afd7887687df1d6ead164/pkg/rest/config_upload.go#L78

Is your feature request related to a problem? Please describe.
The new Dynatrace SLO API started as a preview feature in version 204. Customers, who are part of the preview should be able to leverage the SLO API using Monitoring as Code. Furthermore, when the feature goes GA, we already support it in monaco.

Describe the solution you'd like
Add support for the new SLO API and add a configuration used for the all-configs integration test.

When doing a dry run, it would be great to see the actual diff between the current config in Dynatrace and what we are going to apply.

Reasoning is that in large environments you might loose oversight about what is being changed.

Potentially this output is stored in a file that can be added as an artefact to the build pipeline.

Currently the MaC tool deploys to each environment in sequence.

For a large amount of environments that is an issue, as deployment takes a long time.
From a environment standpoint, there's no reason to not deploy to each in parallel.

In theory it should easily be possible to start a Goroutine for each execute and have them run in parallel rather than in sequence.

Main effort here is taking a close look at any issues we might run into from multithreading:

anything shared between those deployment calls?
any memory issues? e.g. creating a lot of new http client at the same time

Currently, the tool deletes the configs in the delete.yaml file independently of the success of the prior applying of configs.

If the apply fails (for any config) we should skip the delete.

Defining a variable in JSON template within {} (without whitespaces) throws an error. At the moment only possibility it to define whole string in yaml which could be a bit cumbersome. This is e.g. needed if defining http monitor with credentials:

Api-Token {{{ .apiTokenId }}|token}

I'm trying to execute a project called "General" that doesn't have any link with any other projects (./monaco -d -v -p="General" -e="./projects/tenants.yaml" projects) and when doing the "dry run", it seems to be doing a validation of another project called "Application", getting the following error message:

_```
" 2020-11-19 18:03:10 INFO Dynatrace Monitoring as Code v1.0.0
2020-11-19 18:03:10 ERROR Could not execute template: template: projects\Application\app-detection-rule\rules.yaml:8:21: executing "projects\Application\app-detection-rule\rules.yaml" at <.Env.URLPATTERN>: map has no entry for key "URLPATTERN"
2020-11-19 18:03:10 ERROR Error while converting file projects\Application\app-detection-rule\rules.yaml: template: projects\Application\app-detection-rule\rules.yaml:8:21: executing "projects\Application\app-detection-rule\rules.yaml" at <.Env.URLPATTERN>:
map has no entry for key "URLPATTERN"

Related to #55
As @UnseenWizzard wrote
"In general the tool reads in all configs - at which point the env var resolution currently happens - in order to be able to handle dependencies between projects.
That is admittedly an imperfect solution for having several projects, or in-progress projects, because as you noticed they all are validated..."
I think this creates additional complexity because all project is validated and if any environment variable is not applicable for an specific project, you need to create all variables in all projects, otherwise it fails.

It should be possible to define one configuration and apply it n times:

autotagging:
  - name: "Cluster[1..45]"
  - tag: "ClusterTag[1..45]"
  - process-group-name:
    - 1: "cluster_prod1-john"
    - 2: "cluster_prod2-mike"
    - 3: "cluster_prod3-tom"
    - 4: "cluster_prod4-michael"
      ...
    - 45: "cluster_prod45-whatsoever"

Counters [1..45] and lists should be supported:

- process-group-name:
    - 1: "cluster_prod1-john"
    - 2: "cluster_prod2-mike"
    - 3: "cluster_prod3-tom"
    - 4: "cluster_prod4-michael"

Allowed are only positive numbers. Counter doesn't have to start with 1.
Counters can be also defined as:

- name: "[1..45] Test"

or

- name: "Configuration [1..45] something"

Only one counter per parameter is allowed

name parameter defines how often is configuration applied and takes on every iteration it's incremental value:
name: "Test [1..45]" has following values: Test 1, Test 2 ... Test 45
If configuration parameters contains counter or list, and name doesn't, then config validation should fail:

autotagging:
  - name: "Cl-Prod"
  - tag: "Cluster[1..45]"
  - process-group-name:
    - 1: "cluster_prod1-john"
    - 2: "cluster_prod2-mike"
    - 3: "cluster_prod3-tom"
    - 4: "cluster_prod4-michael"

The counter size or number of elements in the list must match for all parameters. Something like this is not allowed:

  - name: "Cl-Prod"
  - tag: "Cluster[1..40]"
  - process-group-name:
    - 1: "cluster_prod1-john"
    - 2: "cluster_prod2-mike"
    - 3: "cluster_prod3-tom"
    - 4: "cluster_prod4-michael"

It seems that verbose logging is not working anymore.

Test are failing due to kubernetes credentials requiring unique endpointUrl. If credentials defined in cmd/monaco/test-resources/integration-all-configs/project/kubernetes-credentials/kubernetes.json are deployed once and (still) not cleaned, tests are going to fail.

We need to have a mechanism for specifying additional APIs which are present at Dynatrace, but which we haven't included in the api.go currently. api.go contains the APIs which are already well-tested. However, there are a lot of other APIs which we didn't need before - so we never added them to the tooling.

In order to support these APIs, we want to perform the following actions:

• add a program argument for specifying a path to a yaml file
• the yaml file is a simple list, which specifies is in the following format:

apis:
  - some-new-api: path-to-api
  - some-new-api-2: path-to-api-2

• these APIs should be usable in addition to the one listes in api.go

Describe the bug
I recently switched out the environments used for the integration tests. Now the used synthetic location in one of the tests is not correct anymore. This causes the build to fail.

How to reproduce
Simply run the integration tests

Expected behavior
The integration tests should work again.

Log output

2020-11-25 08:50:20 ERROR Deployment to environment1 failed with error Failed to upsert DT object Federation Availability_1606294218698578794AllConfigs (HTTP 400)!
    Response was: {"error":{"code":400,"message":"Unknown location(s): [GEOLOCATION-DD9455EF49BF2F89]"}}, responsible config: test-resources/integration-all-configs/project/synthetic-monitor/availabilty.json
2020-11-25 08:50:20 INFO  Deleting 19 configs for environment environment1...
    all_configs_integration_test.go:44: assertion failed: -1 (statusCode int) != 0 (int)

Environment (please complete the following information):

• OS: All

At the moment only configuration parameters are applied to templates, but it would be good to have more information there:

• environment object (e.g. environment url name or group)
• project name
  ....

See the following comment here:

Because the `env-token-name` property is implemented in a way to serve as a usability improvement. The actual token is read from the environment variable as soon as something is applied to an environment and not before that. This ensures, that:
* a dry-run doesn't need any tokens
* you only need to provide the token for the environment you want to apply the configs to

E.g.: in your `environments.yaml` you defined 2 environments (dev and prod) and you just want to apply the configs to dev. To do that, you don't need to have the token for prod set as an environment variable.

There are several Configurations that rely on secrets - e.g. AWS credentials, kubernetes credentials, secret vault secrets for synthetic tests, ... - but the tool currently has no way to deal with secrets in a secure way.

Deletion of configuration is currently defined on project folder root level.

However, for a customer's perspective, it would make sense to allow project-specific deletion as well. A project for a customer could be a particular application (or group of) and these configurations are often handled separately from other projects. For example: I only want to delete a request attribute related to project (= customer application) X.

For initial work with Dynatrace Monitoring as Code, customers would like to be able to download all the current configuration into a project structure.

For example, when running MaC with a flag (e.g.: download), all the supported configurations are downloaded and stored in a new project folder with the entire structure in place, as well as an initial .yaml file to apply. Optionally, the user can specify a list of configuration types that they want to download (e.g.: if they only want management-zones and auto-tag).

This will help existing customers to get started with MaC and start migrating their existing config over.

Describe the bug
Monaco fails for synthetic tests when a variable uses special characters. However passing the same string directly via JSON works.

How to reproduce

my_config:
  - ua_string: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36"

and

{
...
  "script": {
    "configuration": {
      "userAgent": "{{ .ua_string }}"
    }
  }
...
}

Fails with (line 11 is the userAgent line):

Response was: {"error":{"code":400,"message":"Could not map JSON at 'script' near line 11 column 20"}}, responsible config: projects\baseconfig\synthetic-monitor\myfile.json

Whereas removing that YAML variable and pushing this, works just fine.

{
...
  "script": {
    "configuration": {
      "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36"
    }
  }
...
}

• check if API exists that allows that
• make it possible to reference meId for related objects

Having to fill MeIDs into e.g. dashboard configs is tedious.

We'd like to automate that and allow to just reference other configs and have a dashboard auto-filled.

However MeIDs of e.g. a Service do not map to the service detection rule ID, and aren't even available until data is first picked up.

How would we want the tool to handle this?

• Fail until IDs are available?
• Ignore the error until later deployments?
• Wait during deployment until IDs are available?
  ....

Describe the bug
Our integration tests fail.

How to reproduce
Run integration tests against a current SaaS production environment.

Expected behavior
Integration tests work.

Log output

=== RUN   TestDoCleanup
2020-11-23 07:41:36 ERROR Cannot unmarshal API response for existing objects: invalid character '<' looking for beginning of value
    cleanup_all_configs_test.go:50: assertion failed: error is not nil: invalid character '<' looking for beginning of value
--- FAIL: TestDoCleanup (3.86s)
FAIL
FAIL	github.com/dynatrace-oss/dynatrace-monitoring-as-code/cmd/monaco	3.863s
?   	github.com/dynatrace-oss/dynatrace-monitoring-as-code/pkg/api	[no test files]
?   	github.com/dynatrace-oss/dynatrace-monitoring-as-code/pkg/config	[no test files]
?   	github.com/dynatrace-oss/dynatrace-monitoring-as-code/pkg/delete	[no test files]
?   	github.com/dynatrace-oss/dynatrace-monitoring-as-code/pkg/environment	[no test files]
?   	github.com/dynatrace-oss/dynatrace-monitoring-as-code/pkg/project	[no test files]
?   	github.com/dynatrace-oss/dynatrace-monitoring-as-code/pkg/rest	[no test files]
?   	github.com/dynatrace-oss/dynatrace-monitoring-as-code/pkg/util	[no test files]
?   	github.com/dynatrace-oss/dynatrace-monitoring-as-code/pkg/version	[no test files]
FAIL
make: *** [integration-test] Error 1
Makefile:25: recipe for target 'integration-test' failed
Error: Process completed with exit code 2.

Environment (please complete the following information):

• OS: github build env ubuntu-latest
• Tool version 1.0.0 & 1.0.1

Having open sourced our work, we want to open our communication channels as well.
That means moving away from our internal Slack channels to something that external contributors [0] can use as well.

Let's use this to discuss options!

A few ideas:
Slack - pro: extra workspace can just be opened in Slack apps we already use internally all the time, con: text only
Discord - pro: widely used, has voice chat, con: extra tool

Decision Deadline: 2020-12-12
Participation Required: @didiladi , @tatomir146 , @CruzanCaramele

[0] e.g. @goberchtold (testing if reaching out this way works)

Readme suggests the flags use double dashes. For example --dry-run but the v1.0.0 binary still uses single dashes eg. -dry-run

The CONTRIBUTING.MD file says that go build ./... should work fine but it seems that this is not correct. Instead, being in the project's root directory you need to run go build ./cmd/... it seems and then it spits out the monaco binary.

If I'm not overlooking anything then this should be fixed in the documentation. If no one has any more input on this I'd gladly adjust the documentation and create a PR for it :)