Proposal - More generic names for environment properties

[rszulgo]

I plan to add a support for Dynatrace Managed and Cluster configuration and permission REST API. Therefore, I'd like to reuse "environments" concept as it is now with an addition to specify a "cluster environment". For example:

cluster.production-cluster:
  - name: "prod-cluster"
  - env-url: "{{ .Env.CLUSTER_PROD }}"
  - env-token-name: "TOKEN_SERVICE_PROVIDER_API"
  - type: "cluster"
production.environment1:
  - name: "environment1"
  - env-url: "{{ .Env.URL_ENVIRONMENT_1 }}"
  - env-token-name: "TOKEN_ENVIRONMENT_1"

As you see in the example above, existing environment property names could be more intuitive. I'm proposing to change property names, by adding new ones, and deprecating existing ones as following:

• env-url to url
• env-token-name to token
• new property type with a value cluster to differentiate environment types. If skipped then by default it's "environment" type.

What do you think?

[tatomir146]

I like this idea, env seems anyways to be unnecessary there. But I would probably also skip the type: "cluster" part. It would anyways be a good idea to have another command (e.g. monaco deploy-cluster) which would then anyways assume we are in cluster context and it requires clusters.yaml file. Even thought it would be possible to store clusters and environments into single file, IMO it would be better to separate these just to not cause any confusion. First could be named clusters.yaml and the second environments.yaml.

[rszulgo]

That's what we talked about. But when I started to implement this, there was much of duplicated code. And still I thought about usage if this. As a user I'd actually like to have a cluster and environments in one file and run in the pipeline just monaco deploy to apply all changes. No matter if they apply to the cluster or to environments.

[tatomir146]

We anyways have to refactor a lot because we can definitely use most environment methods for cluster config too. Question:
usually deploy requiers project(s) folder parameter, how would you distinguish between env and cluster config?

[rszulgo]

how would you distinguish between env and cluster config?

In code. So the structure of Api definition is extended for clusterConfig boolean:

type apiInput struct {
	apiPath                      string
	propertyNameOfGetAllResponse string
        clusterConfig boolean
}

For instance:

...
         "slo": {
		apiPath:                      "/api/v2/slo",
		propertyNameOfGetAllResponse: "slo",
                clusterConfig: false
	},
        "iam": {
                 apiPath:            "/api/cluster/v2/iam/repo"
                 propertyNameOfGetAllResponse: "policies",
                 clusterConfig: true
                 },
...

[didiladi]

Hmm, I have the feeling that the number of properties in apiInput gets slowly out of hand if we add more and more attributes. This makes it more difficult for users adding additional APIs to monaco. 🤔 How about a second map holding the cluster APIs?

[didiladi]

I also like the idea, because its easier fom a user's perspective and you can re-use a ton of code which is already in monaco.

Regarding the deprecation of the properties env-url, env-token-name: Let's introduce the new properties in addition to the old ones and print a warning when a user still uses the deprecated ones. After some time (in the next major) we can remove the deprecated properties.

@rszulgo in your example, would that reflect a cluster (production) and an environemnt environment1 which is running on the very same cluster? 🤔 The reason I'm asking: I see some problems with the example you provided: By naming the environment group production the same as the cluster production could cause problems when specifying a config override.

[rszulgo]

@rszulgo in your example, would that reflect a cluster (production) and an environemnt environment1 which is running on the very same cluster? 🤔 The reason I'm asking: I see some problems with the example you provided: By naming the environment group production the same as the cluster production could cause problems when specifying a config override.

OK, I've updated the example for the clarity.