github dynatrace-oss/terraform-provider-dynatrace v1.7.0

latest releases: v1.59.0, v1.58.6, v1.58.5...
2 years ago

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.

Don't miss a new terraform-provider-dynatrace release

NewReleases is sending notifications on new releases.