v1.8.3

Release v1.8.3 takes care of #86 and #87.

v1.8.2

Release v1.8.1 unfortunately didn't fix #4 properly. This release takes care of it.

v1.8.1

Release v1.8.1 fixes the following bugs:
#84 The DataSource dynatrace_synthetic_location didn't contain the Dynatrace EntityID when configured with a name only
#85 Resources dynatrace_http_ monitor and dynatrace_browser_monitor failed to deserialize when they were related to management zones.

v1.8.0

Release v1.80 contains the following changes and features:

• Introduced Resource dynatrace_span_attribute.

• Introduced Resources dynatrace_browser_monitor and dynatrace_synthetic_monitor. In order to make configuration of these monitors somewhat convenient, the DataSources dynatrace_credentials, dynatrace_synthetic_location and dynatrace_synthetic_locations were also introduced. Any feedback, especially about Synthetic Monitors will be very welcome.

• Thanks to @JosephHobbs for his contribution to proper and correct documentation of resource dynatrace_disk_anomalies.

• Thanks to @Forcebyte for contributing documentation about Using API Parameters not supported by this module

• String properties within .tf files generated using the terraform-provider-dynatrace.exe export functionality are now in Indented Heredocs format in case they consist of multiple lines. This decision originates from the fact that the newly introduced resources can contain quite a lot of Javascript code - which would be impossible to maintain when represented in excaped JSON notation.

v1.7.3

Release v1.7.3 fixes a few urgent bugs:

• #75 Updating AWS Credentials fails
• #77 Azure Credentials couldn't get created when monitor_only_tagged_entties is set to false
• #73 Supporting Service for AWS Credentials were assigned to wrong JSON attribute

v1.7.2

Release v1.7.1 unfortunately introduced a regression bug (#72), which needs to get fixed. In addition to that it didn't come with the most recent documentation on the Terraform Registry.
Furthermore v1.7.2 contains additional routines in order to diagnose #65 properly.

v1.7.1

Release v1.7.1 takes care of a couple of bugs that have been discovered in the past few weeks and/or emerged due to breaking changes in the REST API of Dynatrace.

• The resource dynatrace_k8s_credentials now supports the attribute event_analysis_and_alerting_enabled
• The resource dynatrace_slo now supports the attribute metric_expression. It is still supported to configurea an SLO using the attributes numerator and denominator, but the configuration automatically will get converted to use metric_expression. This behavior is due to a breaking change in the behavior of the REST API.
• The resource dynatrace_custom_anomalies now supports the attribute metric_selector.
• Fixed #64: Conditions of kind custom_process_metadata were using the wrong value for the attribute type. The affected resources are dynatrace_autotag, dynatrace_managementzone, dynatrace_service_naming, dynatrace_host_naming and dynatrace_process_group_naming.
• Creating resources dynatrace_slo sporadically led to the resource not being reachable right away and potentially even led to flawed terraform states. This has now been fixed.

v1.7.0

Release v1.7.0 introduces support for the following resources:

• dynatrace_dashboard_sharing
• dynatrace_environment
• dynatrace_mobile_application

The resource dynatrace_dashboard_sharing allows for managing sharing settings for Dashboards. A recent change in the Dynatrace REST API decoupled that functionality from the core dashboard settings.
When using terraform-provider-dynatrace export the resources for dashboard sharing can be found within the .tf files of the exported Dashboards.
You may however chose to not apply that resource if it's configuration looks like this (which means no specific share settings have been applied so far).

resource "dynatrace_dashboard_sharing" "<dashboard-name>" {
  enabled = true
  dashboard_id = "<dashboard-id"
  preset = true
  permissions {
    permission {
      type = "ALL"
      level = "VIEW"
    }
  }
}

The resource dynatrace_environment is the first resource targeting the Dynatrace Cluster API (as apposed to the REST API of a specific Environment).
While it's technically possible to use one and the same provider instance for both, Environment API and Cluster API, it's recommended to work with a second instance of the Dynatrace Provider in order to use that resource. Instead of the well known configuration properties dt_env_url and dt_api_token the properties dt_cluster_url and dt_cluster_api_token are then relevant.

provider "dynatrace" {
  dt_cluster_url   = "https://your-dynatrace-managed-host"
  dt_cluster_api_token = "##########################################"
}  

Dynatrace Environments are not covered by the terraform-provider-dynatrace export functionality, because the credentials specifically refer to an already existing Dynatrace Environment.
Instead terraform-provider-dynatrace.exe cluster_export can be used to export existing Environments from a Managed Dynatrace Cluster.

The resource dynatrace_mobile_application allows for configuring settings for Mobile Applications, Key User Actions as well as Session- and UserAction-Properties for such an Application. Applying a fully configured dynatrace_mobile_application eventually requires multiple REST API Calls (the core settings for the mobile application is separate from Key User Actions and Session-Properties). You may therefore experience delays during the initial creation of a mobile application.

Creating a Mobile Application allows to optionally specify the application_id (the unique identifier used by the Dynatrace Agent when referring to this application).

resource "dynatrace_mobile_application" "mobile-app-name" {
  name                    = "mobile-app-name"
  application_id          = "6aa7a5a0-0bdd-41fa-b888-7293f1871d5c"
  ...
}

But it's also possible to have Dynatrace generate that application_id for you if you choose so.

resource "dynatrace_mobile_application" "mobile-app-name" {
  name                    = "mobile-app-name"  
  ...
}

The second option will result in your terraform state containing the generated application_id - therefore a terraform plan will notify you that your .tf file needs to get amended.

• Release v1.8.0 will focus on User- and Group-Management and API-Token Management on the cluster level.
• The next resource planned to be implemented on Environment level will be Synthetic Monitors.

v1.6.1

Release v1.6.1 introduces support for the following resources:

• dynatrace_span_entry_point
• dynatrace_span_capture_rule
• dynatrace_span_context_propagation
• dynatrace_resource_attributes

The REST API for OpenTelemetry Settings is still considered "Early Access" by Dynatrace, therefore it's possible that the HCL schema for the above resources might change slightly in the future. Existing `.'tf' files are however unlikely going to become invalid. It's rather possible that additional attributes may be getting introduced in future versions.

Release v1.6.1 fixes #47: Dashboards restricted by Management Zone couldn't get created

Release v1.7.0 will focus on configuring Dashboard Sharing and creating Environments using the Cluster API.

v1.6.0

Release v1.6.0 introduces support for the following resources:

• dynatrace_span_entry_point
• dynatrace_span_capture_rule
• dynatrace_span_context_propagation
• dynatrace_resource_attributes

The REST API for OpenTelemetry Settings is still considered "Early Access" by Dynatrace, therefore it's possible that the HCL schema for the above resources might change slightly in the future. Existing `.'tf' files are however unlikely going to become invalid. It's rather possible that additional attributes may be getting introduced in future versions.

Release v1.7.0 will focus on configuring Dashboard Sharing and creating Environments using the Cluster API.