Story

I want to be able to configure alerting channels
So that I can setup event management and altering end-by-end in terraform

Technical Details

Alerting channels come in multiple flavours. Each flavour should be represented by an individual terraform resource to provide ease of use and proper input validation.

https://instana.github.io/openapi/#operation/putAlertingChannel

Story

I want to be able to manage user groups as a replacement for resource instana_user_role
So that I again can manage the permission of groups in the terraform provider

I tried to recreate the mocks following the readme and had no luck to recreate what is currently comitted.
Also the existing generated mocks mention instana/restapi/api.go which is no longer present since #35

Story

I want to be able to configure SLIs through terraform
So that I can consistently roll out SLIs for different environments

Technical Details

SLIs is a relatively new feature of Instana. In the UI they can only be configured through custom dashboards. The API also provides endpoints to configure SLIs:
https://instana.github.io/openapi/#operation/createSli

Replace plain go if checks in tests with testify assert

With #48 we fixed an incompatibility of the Instana API with a former version. In the meantime Instana changed their implementation to be compatible with the former version again.

The change of #48 is still valid and ensures that the API is stable. However with this we do not allow the Instana representation in terraform. The instana value is the same as for the Matching Operator of dynamic built in metrics as introduced with #47.

For compatibility we should also support the Instana representation (additionally) and store the instana representation in the state as unified harmonized value. This requires a state mgiration

To release the terraform provider to the new github registry documentation needs to be provided in a specific format (see also https://www.terraform.io/docs/registry/providers/docs.html)
To avoid double work the documentation of this page should be change to github pages using a similar structure as requested by the terraform provider registry

Application configurations support the additional configuration of a boundary_scope. Add this field also to the terraform provider.

Story

I want be able to setup maintenance configurations
So that I can activate/deactivate maintenance windows automatically with the infrastructure code when changes are applied/scheduled

Technical Details

Maintenance windows are easy to configure and do not have a complex structure.
https://instana.github.io/openapi/#operation/putMaintenanceConfig

Story

I want to be able to manage application perspectives through the terraform provider
So that I create a common setting for all stages

I am in the need to support Application Alert Configs.
I have created a branch that currently does just enough for me:
https://github.com/martinei/terraform-provider-instana/tree/application_config_alerts

I am aware this is not "good enough" to be merged, but maybe it is still useful for someone or can serve as a starting point.

There's a difference between writing

resource "instana_alerting_config" "my_resource" {
  alert_name               = "my-resource-alert"
  integration_ids          = ["${instana_alerting_channel_slack.alert_channel_in_slack.id}"]
  event_filter_query       = "entity.application.id:\"${instana_application_config.application_all.id}\""
  event_filter_event_types = ["critical", "incident", "warning"]
}

and

resource "instana_alerting_config" "my_ressource" {
  alert_name               = "my-ressource-alert"
  integration_ids          = ["${instana_alerting_channel_slack.alert_channel_in_slack.id}"]
  event_filter_query       = "entity.application.id:\"${instana_application_config.application_all.id}\""
  event_filter_event_types = ["incident", "critical", "warning"]
}

If written in the "human"-order of descending priorities / event_filter_event_types, you'd constantly get some changes on a terraform apply:

  # instana_alerting_config.alerting_eCom_general will be updated in-place
  ~ resource "instana_alerting_config" "my_resource" {
        alert_name               = "my-resource-alert"
      ~ event_filter_event_types = [
          - "critical",
            "incident",
          + "critical",
            "warning",
        ]
        event_filter_query       = "***************"
        event_filter_rule_ids    = []
        full_alert_name          = " my-resource-alert (TF)"
        id                       = "***************"
        integration_ids          = [
            "***************",
        ]
    }

If the priorities / event_filter_event_types are defined in alphabetical order, there will be no change.

This issue has only low priority.

Background

Instana has change the role resource in the REST API. With the changes new permissions can be configured. Furthermore the ImplicitViewFilter option has been removed.

TODO

Remove configuration option ImplicitViewFilter. Needs state migration!
Add new permissions:

• CanConfigureMobileAppMonitoring
• CanConfigureTeams
• RestrictedAccess
• CanConfigureReleases
• CanConfigureLogManagement
• CanCreatePublicCustomDashboards
• CanViewLogs
• CanViewTraceDetails

In Release 188 Instana changed the EQUAL condition operator from == to =.
This is a breaking change and needs to be adopted in the Terraform Provider.

Ideally the provider should support both options to stay compatible.

Currently the threshold rule only supports either window or rule. However regarding instana API both options are supported also together.

Story

I want that the rule type entity verification is supported
So that I can configure corresponding custom events in the system

Technical Details

Instana added support for a new rule type - entity verification. This type of events is used e.g. to configure a custom event which is triggered when a service is not running on a certain host.

Story

I want to be able to define a prefix and a suffix which should be added to each name or label
So that my resources get a consistent naming within e.g. a particular environment

Technical Details

With #19 the option append the string ' (TF managed)' was added to the provider. This helps to identify that a resource is managed by terraform but is already very opinionated and restricted.

With this story the options for a default prefix and suffix for resource names/labels should be provided.

• By default there should be no prefix
• By default the suffix should be set to ' (TF managed)'

The configuration option of #19 becomes obsolete with this change and can be deleted.
The resources should be migrated properly.

Story

I want to be able to manage user groups through the terraform provider
So that I manage my groups consistently through infrastructure as code

Instana provides additional operator types for application configurations. Add them to the terraform provider. This requires a change to the parser. The added types are:

• STARTS_WITH
• ENDS_WITH
• NOT_STARTS_WITH
• NOT_ENDS_WITH
• GREATER_OR_EQUAL_THAN
• LESS_OR_EQUAL_THAN
• LESS_THAN
• GREATER_THAN

Hey @gessnerfl doing great work,
wanted to have application perspective to be added to instana_alerting_config,
Because i can see no argument under alert config so need to add that in your repo to support adding application perspective for our alerts.
we are able to use DFQ,all entities option, but not the Application perspective.
how to go with that, can we get any help from here

Custom Events do not support downstream integrationIds anymore
Please remove them also from the terraform provider

Instana Server (on-premise) supports more than six event_filter_rule_ids item per alert.

According to the API-documention the limit of rule-ids is 1024:
https://instana.github.io/openapi/#operation/putAlert

Example of the error:
`Error: event_filter_rule_ids: attribute supports 6 item maximum, config has 9 declared

on main.tf line 229, in resource "instana_alerting_config" "alerting_test":
229: resource "instana_alerting_config" "alerting_test" {`

Story

As a SRE/DevOps Engineer
I want to be able to configure custom events of rule type "Threshold Rule using a dynamic built-in metric by pattern"
So that I can also use the new feature in the terraform provider and with this configure precise events for my service

Technical Details

With release 177 (https://www.instana.com/docs/releases/notes/build_177/) custom events of type threshold rule where extended to support filtering of built in metrics for different entity types. With this it is possible to e.g. configure alters for specific disks or messaging queues.

Task

Extend the terraform provider to also map these fields so that users can also configure these kind of custom events through the terraform provider.

gosec (https://github.com/securego/gosec) is a static code analysis tool for git. Integrate this tool to check the terraform provider against common security standards.

The tool should be integrated in the Makefile (all goal) as well as the CI/CD build pipeline

Story

I want that for each resource a string is appended to the description text or if not available to the name/label field
So that I can see in the UI if a resource is managed by terraform or created manually

Technical Details

To avoid that users delete resources which were created by the terraform provider, a string should be appended to the description text when available or alternatively to the name/label. With this users can see if a resource was created manually in the UI or through terraform.

Name/Label text: ' (tf managed)'
Description text: '\n\n--\nterraform managed'

Story

I want to be able to configure synthetic endpoints
So that I can manage synthetic endpoint configurations consistently across tenants

Technical Details

Synthetic endpoints are managed globally within a tenant (Applications -> Services -> Configure Services -> Synthetic Endpoints. To provide an option to configure this endpoints also through infrastructure code the provider should be extended by this feature.
https://instana.github.io/openapi/#operation/getSyntheticCalls

Story

As a developer
I want that the REST API client is being generated from the OpenAPI spec
So that I can focus on implementing the terraform resources only

Technical Details

The REST API client for the Instana API can be generated using a tool as described here: https://instana.github.io/openapi/#section/Generating-REST-API-clients

With this the effort of implementing new features is reduced to mainly adding the resource with a proper schema. Implementation and maintenance effort will be reduced significantly

Story

As a developer
I want that all resources are encapsulated into structs
So that we have a more clean organization of our code and get rid of the very long function names

Technical Background

Currently all terraform resources are implemented as simple go script files. The idea of this issue is to change them to a struct/object so that the implementation is encapsulated in the struct/object. All resources should implement an interface similar to the data sources. With this the code will be better organized and functions can have shorter names

Story

I want that the terraform-provider-instana is using the new OpenAPI based REST service
So that the provider is working also in future when the deprecated interfaces are shutdown

Technical Details

Instanas OpenAP based RESTful interface is not out of beta and with this became the recommended interface. The Postman based API is now deprecated. To be ready for future enhancements the provider implementation should switch to the OpenAPI based implementation

You are doing a great work @gessnerfl thank you.

Would be nice the terraform resource in order to also create the websites configurations - https://instana.github.io/openapi/#tag/Website-Configuration

Migrate CI/CD from travis to github actions. Use gorelease (https://goreleaser.com/) to release the project according to the terraform registry requirements

Hi, i'd like to understand how to set the entity ('Destination' or 'Source') within the matchspecification of an application configuration.
The Instana APi https://instana.github.io/openapi/#operation/addApplicationConfig marks the field 'entity' as required.
If i create a match specification like 'kubernetes.namespace EQUALS 'xyz' via the terraform-provider-instana, the result is an application config with a match specification of type 'Destination'.
How can i achieve a match specification of type 'Source'?
Thanks a lot!

Instana API changed the ENUMs of the 'matching_operator` of custom event:

• starts_with => startsWith
• ends_with => endsWith

Ideally we can translate to the new values in the terraform provider so that we can keep the api stable

Story

As a system operator
I want that the terraform-provider-instana is bundled in the same way as all other providers (as zip and following the naming convention <plugin_name>_<plugin_version>_<platform>)
So that I can use it in the same way as all other plugins

Technical Details

Currently the plugin is released without version information in the zip file and without version and platform information for the binary file. To be compliant to other providers the naming should be changed such as that it always contains the version and the platform:

<plugin_name>_<plugin_version>_<platform>

Story

I want that the rest client is retying operations when Instana API is rejecting a request with HTTP code 500 (Body = Maximum write attempts reached, write is aborted)
So that changes get applied in a stable way when rate limiting or similar controls apply

Technical Details

When having several resources defined for Instana operations partly fails. When applying again the changes the change is successful. The issue is that Instana is rejecting the requests with an HTTP 500 and the error message 'Maximum write attempts reached, write is aborted'. It seems that only certain number of write operations are allowed at a time. To mitigate this the client should implement a retry logic so that such errors get fixed automatically

Using Terraform 0.14.4 I got this error on 2020-02-02 14:45 UTC
(if this is a caching issue or similar)

Initializing the backend...

Initializing provider plugins...
- Finding gessnerfl/instana versions matching "0.10.0"...
- Installing gessnerfl/instana v0.10.0...
Error: Failed to install provider

Error while installing gessnerfl/instana v0.10.0: checksum list has unexpected
SHA-256 hash a37c4f79c5a1d926486ebb66a27f2ecc547d868cb1c17f92107a5b3196a93783
(expected da9ab5cc67035d6500a6e764ba466c0e69662eae7fd959f132563c4cbfb17701)

terraform {
  required_providers {
    instana = {
      source  = "gessnerfl/instana"
      version = "0.10.0"
    }
  }
  required_version = ">= 0.13"
}

Bug Report

Instana just deleted the Role resource from their rest api. Because of this roles cannot be managed anymore in Instana.
However roles are now replaced with groups because of this the role resource should be deleted.

Instana added an additional event type for alerts agent_monitoring_issue. Add this event type to the terraform provider.

Story

I want that the provider is updated to terraform 0.12.x
So that I can use the improved syntax

I need to create an "instana_application_config" with

match_specification = "kubernetes.pod.label.foo/bar EQUALS 'blub'"

The "/" is not allowed by the plugin. This Regex should also allow "/".

Instana itself has not problem with "/" beeing part of the label name.

We wanted to add builtin events that exist in instana to the alerts that are managed by terraform.
as i could see there is no entity to add via DFQ
So can you help me with a way to add builtin events for alerts created terraform

All resources should be migrated to the new generic approach to reduce boilerplate code

Story

I want to be able to manage users through the terraform provider
So that I manage my users consistently through infrastructure as code

With #15 we change the release to zip and changed the file names to terraform-provider-instana-<version>-<platform>. This name is fine but it should changed for the executable to terraform-provider-instana-<version> as it will otherwise not be considered by terraform

Hi!

We added the following patch to instana/filterexpression/filter-expression-parser.go to support dashes for tags like call.http.header.x-example-foo in match_specification.

@@ -109,7 +109,7 @@ func (e *UnaryOperationExpression) Render() string {
 var (
        filterLexer = lexer.Must(lexer.Regexp(`(\s+)` +
                `|(?P<Keyword>(?i)OR|AND|TRUE|FALSE|IS_EMPTY|NOT_EMPTY|IS_BLANK|NOT_BLANK|EQUALS|NOT_EQUAL|CONTAINS|NOT_CONTAIN)` +
-               `|(?P<Ident>[a-zA-Z_][\.a-zA-Z0-9_]*)` +
+               `|(?P<Ident>[a-zA-Z_][\.a-zA-Z0-9_-]*)` +
                `|(?P<Number>[-+]?\d+(\.\d+)?)` +
                `|(?P<String>'[^']*'|"[^"]*")` +
                `|(?P<Operators>EQUALS|NOT_EQUAL|CONTAINS|NOT_CONTAIN|IS_EMPTY|NOT_EMPTY|IS_BLANK|NOT_BLANK)`,

We would have sent a pull request, but we weren't able to fix your tests. It would be nice to have support for this added officially.

Story

I want to be able to configure Alerting rules through terraform
So that I can setup eventing and alerting together with alerting channels end-by-end in infrastructure code.

Technical Details

Alerting configurations support either event types or selected events:
https://instana.github.io/openapi/#operation/putAlert

Story

As a developer
I want to migrate the provider to the latest Plugin SDK version 2
To avoid future deprecation

Story

As a developer
I want that the Rest Resource are adopted such as that it supports Create and Update operations instead of only providing an Upsert operation
So that the Rest Resource fits to endpoints of the instana API implementing such a behaviour.

Implementation Details

Currently the all resources which are implemented by the provider are using a common pattern with a PUT endpoint for create and update of the resource. However resources such as web site monitoring or users have separated endpoints for create and update. The implementation should be adjusted such as that this pattern is supported. Therefore the interface should be adopted and a base implementation should be provided where POST is used for create and PUT is used for update operations.

Story

As a user of the terraform provider instana
I want that severity for rule bindings (and with #7 also for events) is configurable in a user friendly way
So that I do not have to know the internals of the instana API

Technical Background

In the Instana API the severity of a issue created through a rule binding or an event is reflected by the values:

• 5 = Warning
• 10 = Critical

Basically the provider should use meaningful names instead of the integer representations to simplify the configuration

Story

I want to be able to manage users through the terraform provider
So that I manage my users consistently through infrastructure as code

Background

With the new OpenAPI it is possible to create events (combination of rule + rule binding + downstream alerting) in a single step. This option should be provided also in the terraform provider to simplify infrastructure code