Dynatrace/dynatrace-configuration-as-code

Dependency suffixes causes issues for top-level domain .id and .name

163a opened this issue · 1 comments

163a commented

Describe the bug
Monaco interprets string data containing .id as references to the ID property, rather than as a string.

How to reproduce
Consider the following app detection rule, which ties www.domainname.id to a web application:

config:
    www-domainname-id-domain-detection-rule: domain-detection-rule.json

www-domainname-id-domain-detection-rule:
  - name: "www.domainname.id"
  - pattern: "www.domainname.id"
  - applicationIdentifier: "projects/matrix/application-web/application-web.id"

Both name and pattern are problematic, as the TLD of the domain is being treated as an ID property, leading the domain itself being incorrectly interpreted as a dependency reference.

From config.go (version v1.8.7):

var dependencySuffixes = []string{".id", ".name"}
...
func isDependency(property string) bool {
    for _, suffix := range dependencySuffixes {
        if strings.HasSuffix(property, suffix) {
            return true
        }
    }
    return false
}

Expected behavior
www.domainname.id is interpreted as a string and not a reference.

Log output
This leads to an error along the following lines:

2023-03-02 02:12:36 DEBUG   Validating config monitoring-mount/.deploy/20230302_131226/projects/matrix/app-detection-rule-v2/domain-detection-rule.json
2023-03-02 02:12:36 DEBUG           property www.domainname.id contains more than the single expected `.` separator, using last separator for split
2023-03-02 02:12:36 ERROR           Failed Id 'www.domainname' was not available. Please make sure the reference exists.

Environment (please complete the following information):

  • OS: [e.g. Win 10, Ubuntu Linux, macOs Catalina]
  • Tool version 1.8.7

Additional context
Perhaps a way to escape the dependency suffixes would need to be implemented.

UnseenWizzard commented

Sorry @163a, I thought I had replied to this!

As you already point out this is caused by how monaco 1.x interprets references as a string (possible defining project and type via '/' seperators) ending in .id or .name.

Monaco 2.x makes references explicit and does not have this issue in either full or shorthand form of references:
https://www.dynatrace.com/support/help/manage/configuration-as-code/configuration/yaml-configuration#reference

As 2.x is about to release, this issue won't be addressed in a 1.x bugfix.
You can already try the latest pre-release here: https://github.com/Dynatrace/dynatrace-configuration-as-code/releases/tag/v2.0.0-rc.6