terraform/website/source/docs/providers/circonus/r/contact_group.html.markdown

290 lines
8.5 KiB
Markdown
Raw Normal View History

Circonus Provider (#12338) * Begin stubbing out the Circonus provider. * Remove all references to `reverse:secret_key`. This value is dynamically set by the service and unused by Terraform. * Update the `circonus_check` resource. Still a WIP. * Add docs for the `circonus_check` resource. Commit miss, this should have been included in the last commit. * "Fix" serializing check tags I still need to figure out how I can make them order agnostic w/o using a TypeSet. I'm worried that's what I'm going to have to do. * Spike a quick circonus_broker data source. * Convert tags to a Set so the order does not matter. * Add a `circonus_account` data source. * Correctly spell account. Pointed out by: @postwait * Add the `circonus_contact_group` resource. * Push descriptions into their own file in order to reduce the busyness of the schema when reviewing code. * Rename `circonus_broker` and `broker` to `circonus_collector` and `collector`, respectively. Change made with concent by Circonus to reduce confusion (@postwait, @maier, and several others). * Use upstream contsants where available. * Import the latest circonus-gometrics. * Move to using a Set of collectors vs a list attached to a single attribute. * Rename "cid" to "id" in the circonus_account data source and elsewhere where possible. * Inject a tag automatically. Update gometrics. * Checkpoint `circonus_metric` resource. * Enable provider-level auto-tagging. This is disabled by default. * Rearrange metric. This is an experimental "style" of a provider. We'll see. That moment. When you think you've gone off the rails on a mad scientist experiment but like the outcome and think you may be onto something but haven't proven it to yourself or anyone else yet? That. That exact feeling of semi-confidence while being alone in the wilderness. Please let this not be the Terraform provider equivalent of DJB's C style of coding. We'll know in another resource or two if this was a horrible mistake or not. * Begin moving `resource_circonus_check` over to the new world order/structure: Much of this is WIP and incomplete, but here is the new supported structure: ``` variable "used_metric_name" { default = "_usage`0`_used" } resource "circonus_check" "usage" { # collectors = ["${var.collectors}"] collector { id = "${var.collectors[0]}" } name = "${var.check_name}" notes = "${var.notes}" json { url = "https://${var.target}/account/current" http_headers = { "Accept" = "application/json" "X-Circonus-App-Name" = "TerraformCheck" "X-Circonus-Auth-Token" = "${var.api_token}" } } stream { name = "${circonus_metric.used.name}" tags = "${circonus_metric.used.tags}" type = "${circonus_metric.used.type}" } tags = { source = "circonus" } } resource "circonus_metric" "used" { name = "${var.used_metric_name}" tags = { source = "circonus" } type = "numeric" } ``` * Document the `circonus_metric` resource. * Updated `circonus_check` docs. * If a port was present, automatically set it in the Config. * Alpha sort the check parameters now that they've been renamed. * Fix a handful of panics as a result of the schema changing. * Move back to a `TypeSet` for tags. After a stint with `TypeMap`, move back to `TypeSet`. A set of strings seems to match the API the best. The `map` type was convenient because it reduced the amount of boilerplate, but you loose out on other things. For instance, tags come in the form of `category:value`, so naturally it seems like you could use a map, but you can't without severe loss of functionality because assigning two values to the same category is common. And you can't normalize map input or suppress the output correctly (this was eventually what broke the camel's back). I tried an experiment of normalizing the input to be `category:value` as the key in the map and a value of `""`, but... seee diff suppress. In this case, simple is good. While here bring some cleanups to _Metric since that was my initial testing target. * Rename `providerConfig` to `_ProviderConfig` * Checkpoint the `json` check type. * Fix a few residual issues re: missing descriptions. * Rename `validateRegexp` to `_ValidateRegexp` * Use tags as real sets, not just a slice of strings. * Move the DiffSuppressFunc for tags down to the Elem. * Fix up unit tests to chase the updated, default hasher function being used. * Remove `Computed` attribute from `TypeSet` objects. This fixes a pile of issues re: update that I was having. * Rename functions. `GetStringOk` -> `GetStringOK` `GetSetAsListOk` -> `GetSetAsListOK` `GetIntOk` -> `GetIntOK` * Various small cleanups and comments rolled into a single commit. * Add a `postgresql` check type for the `circonus_check` resource. * Rename various validator functions to be _CapitalCase vs capitalCase. * Err... finish the validator renames. * Add `GetFloat64()` support. * Add `icmp_ping` check type support. * Catch up to the _API*Attr renames. Deliberately left out of the previous commit in order to create a clean example of what is required to add a new check type to the `circonus_check` resource. * Clarify when the `target` attribute is required for the `postgresql` check type. * Correctly pull the metric ID attribute from the right location. * Add a circonus_stream_group resource (a.k.a. a Circonus "metric cluster") * Add support for the [`caql`](https://login.circonus.com/user/docs/caql_reference) check type. * Add support for the `http` check type. * `s/SSL/TLS/g` * Add support for `tcp` check types. * Enumerate the available metrics that are supported for each check type. * Add [`cloudwatch`](https://login.circonus.com/user/docs/Data/CheckTypes/CloudWatch) check type support. * Add a `circonus_trigger` resource (a.k.a Circonus Ruleset). * Rename a handful of functions to make it clear in the function name the direction of flow for information moving through the provider. TL;DR: Replace `parse` and `read` with "foo to bar"-like names. * Fix the attribute name used in a validator. Absent != After. * Set the minimum `absent` predicate to 70s per testing. * Fix the regression tests for circonus_trigger now that absent has a 70s min * Fix up the `tcp` check to require a `host` attribute. Fix tests. It's clear I didn't run these before committing/pushing the `tcp` check last time. * Fix `circonus_check` for `cloudwatch` checks. * Rename `parsePerCheckTypeConfig()` to `_CheckConfigToAPI` to be consistent with other function names. grep(1)ability of code++ * Slack buttons as an integer are string encoded. * Fix updates for `circonus_contact`. * Fix the out parameters for contact groups. * Move to using `_CastSchemaToTF()` where appropriate. * Fix circonus_contact_group. Updates work as expected now. * Use `_StateSet()` in place of `d.Set()` everywhere. * Make a quick pass over the collector datasource to modernize its style * Quick pass for items identified by `golint`. * Fix up collectors * Fix the `json` check type. Reconcile possible sources of drift. Update now works as expected. * Normalize trigger durations to seconds. * Improve the robustness of the state handling for the `circonus_contact_group` resource. * I'm torn on this, but sort the contact groups in the notify list. This does mean that if the first contact group in the list has a higher lexical sort order the plan won't converge until the offending resource is tainted and recreated. But there's also some sorting happening elsewhere, so.... sort and taint for now and this will need to be revisited in the future. * Add support for the `httptrap` check type. * Remove empty units from the state file. * Metric clusters can return a 404. Detect this accordingly in its respective Exists handler. * Add a `circonus_graph` resource. * Fix a handful of bugs in the graph provider. * Re-enable the necessary `ConflictsWith` definitions and normalize attribute names. * Objects that have been deleted via the UI return a 404. Handle in Exists(). * Teach `circonus_graph`'s Stack set to accept nil values. * Set `ForceNew: true` for a graph's name. * Chase various API fixes required to make `circonus_graph` work as expected. * Fix up the handling of sub-1 zoom resolutions for graphs. * Add the `check_by_collector` out parameter to the `circonus_check` resource. * Improve validation of line vs area graphs. Fix graph_style. * Fix up the `logarithmic` graph axis option. * Resolve various trivial `go vet` issues. * Add a stream_group out parameter. * Remove incorrectly applied `Optional` attributes to the `circonus_account` resource. * Remove various `Optional` attributes from the `circonus_collector` data source. * Centralize the common need to suppress leading and trailing whitespace into `suppressWhitespace`. * Sync up with upstream vendor fixes for circonus_graph. * Update the checksum value for the http check. * Chase `circonus_graph`'s underlying `line_style` API object change from `string` to `*string`. * Clean up tests to use a generic terraform regression testing account. * Add support for the MySQL to the `circonus_check` resource. * Begin stubbing out the Circonus provider. * Remove all references to `reverse:secret_key`. This value is dynamically set by the service and unused by Terraform. * Update the `circonus_check` resource. Still a WIP. * Add docs for the `circonus_check` resource. Commit miss, this should have been included in the last commit. * "Fix" serializing check tags I still need to figure out how I can make them order agnostic w/o using a TypeSet. I'm worried that's what I'm going to have to do. * Spike a quick circonus_broker data source. * Convert tags to a Set so the order does not matter. * Add a `circonus_account` data source. * Correctly spell account. Pointed out by: @postwait * Add the `circonus_contact_group` resource. * Push descriptions into their own file in order to reduce the busyness of the schema when reviewing code. * Rename `circonus_broker` and `broker` to `circonus_collector` and `collector`, respectively. Change made with concent by Circonus to reduce confusion (@postwait, @maier, and several others). * Use upstream contsants where available. * Import the latest circonus-gometrics. * Move to using a Set of collectors vs a list attached to a single attribute. * Rename "cid" to "id" in the circonus_account data source and elsewhere where possible. * Inject a tag automatically. Update gometrics. * Checkpoint `circonus_metric` resource. * Enable provider-level auto-tagging. This is disabled by default. * Rearrange metric. This is an experimental "style" of a provider. We'll see. That moment. When you think you've gone off the rails on a mad scientist experiment but like the outcome and think you may be onto something but haven't proven it to yourself or anyone else yet? That. That exact feeling of semi-confidence while being alone in the wilderness. Please let this not be the Terraform provider equivalent of DJB's C style of coding. We'll know in another resource or two if this was a horrible mistake or not. * Begin moving `resource_circonus_check` over to the new world order/structure: Much of this is WIP and incomplete, but here is the new supported structure: ``` variable "used_metric_name" { default = "_usage`0`_used" } resource "circonus_check" "usage" { # collectors = ["${var.collectors}"] collector { id = "${var.collectors[0]}" } name = "${var.check_name}" notes = "${var.notes}" json { url = "https://${var.target}/account/current" http_headers = { "Accept" = "application/json" "X-Circonus-App-Name" = "TerraformCheck" "X-Circonus-Auth-Token" = "${var.api_token}" } } stream { name = "${circonus_metric.used.name}" tags = "${circonus_metric.used.tags}" type = "${circonus_metric.used.type}" } tags = { source = "circonus" } } resource "circonus_metric" "used" { name = "${var.used_metric_name}" tags = { source = "circonus" } type = "numeric" } ``` * Document the `circonus_metric` resource. * Updated `circonus_check` docs. * If a port was present, automatically set it in the Config. * Alpha sort the check parameters now that they've been renamed. * Fix a handful of panics as a result of the schema changing. * Move back to a `TypeSet` for tags. After a stint with `TypeMap`, move back to `TypeSet`. A set of strings seems to match the API the best. The `map` type was convenient because it reduced the amount of boilerplate, but you loose out on other things. For instance, tags come in the form of `category:value`, so naturally it seems like you could use a map, but you can't without severe loss of functionality because assigning two values to the same category is common. And you can't normalize map input or suppress the output correctly (this was eventually what broke the camel's back). I tried an experiment of normalizing the input to be `category:value` as the key in the map and a value of `""`, but... seee diff suppress. In this case, simple is good. While here bring some cleanups to _Metric since that was my initial testing target. * Rename `providerConfig` to `_ProviderConfig` * Checkpoint the `json` check type. * Fix a few residual issues re: missing descriptions. * Rename `validateRegexp` to `_ValidateRegexp` * Use tags as real sets, not just a slice of strings. * Move the DiffSuppressFunc for tags down to the Elem. * Fix up unit tests to chase the updated, default hasher function being used. * Remove `Computed` attribute from `TypeSet` objects. This fixes a pile of issues re: update that I was having. * Rename functions. `GetStringOk` -> `GetStringOK` `GetSetAsListOk` -> `GetSetAsListOK` `GetIntOk` -> `GetIntOK` * Various small cleanups and comments rolled into a single commit. * Add a `postgresql` check type for the `circonus_check` resource. * Rename various validator functions to be _CapitalCase vs capitalCase. * Err... finish the validator renames. * Add `GetFloat64()` support. * Add `icmp_ping` check type support. * Catch up to the _API*Attr renames. Deliberately left out of the previous commit in order to create a clean example of what is required to add a new check type to the `circonus_check` resource. * Clarify when the `target` attribute is required for the `postgresql` check type. * Correctly pull the metric ID attribute from the right location. * Add a circonus_stream_group resource (a.k.a. a Circonus "metric cluster") * Add support for the [`caql`](https://login.circonus.com/user/docs/caql_reference) check type. * Add support for the `http` check type. * `s/SSL/TLS/g` * Add support for `tcp` check types. * Enumerate the available metrics that are supported for each check type. * Add [`cloudwatch`](https://login.circonus.com/user/docs/Data/CheckTypes/CloudWatch) check type support. * Add a `circonus_trigger` resource (a.k.a Circonus Ruleset). * Rename a handful of functions to make it clear in the function name the direction of flow for information moving through the provider. TL;DR: Replace `parse` and `read` with "foo to bar"-like names. * Fix the attribute name used in a validator. Absent != After. * Set the minimum `absent` predicate to 70s per testing. * Fix the regression tests for circonus_trigger now that absent has a 70s min * Fix up the `tcp` check to require a `host` attribute. Fix tests. It's clear I didn't run these before committing/pushing the `tcp` check last time. * Fix `circonus_check` for `cloudwatch` checks. * Rename `parsePerCheckTypeConfig()` to `_CheckConfigToAPI` to be consistent with other function names. grep(1)ability of code++ * Slack buttons as an integer are string encoded. * Fix updates for `circonus_contact`. * Fix the out parameters for contact groups. * Move to using `_CastSchemaToTF()` where appropriate. * Fix circonus_contact_group. Updates work as expected now. * Use `_StateSet()` in place of `d.Set()` everywhere. * Make a quick pass over the collector datasource to modernize its style * Quick pass for items identified by `golint`. * Fix up collectors * Fix the `json` check type. Reconcile possible sources of drift. Update now works as expected. * Normalize trigger durations to seconds. * Improve the robustness of the state handling for the `circonus_contact_group` resource. * I'm torn on this, but sort the contact groups in the notify list. This does mean that if the first contact group in the list has a higher lexical sort order the plan won't converge until the offending resource is tainted and recreated. But there's also some sorting happening elsewhere, so.... sort and taint for now and this will need to be revisited in the future. * Add support for the `httptrap` check type. * Remove empty units from the state file. * Metric clusters can return a 404. Detect this accordingly in its respective Exists handler. * Add a `circonus_graph` resource. * Fix a handful of bugs in the graph provider. * Re-enable the necessary `ConflictsWith` definitions and normalize attribute names. * Objects that have been deleted via the UI return a 404. Handle in Exists(). * Teach `circonus_graph`'s Stack set to accept nil values. * Set `ForceNew: true` for a graph's name. * Chase various API fixes required to make `circonus_graph` work as expected. * Fix up the handling of sub-1 zoom resolutions for graphs. * Add the `check_by_collector` out parameter to the `circonus_check` resource. * Improve validation of line vs area graphs. Fix graph_style. * Fix up the `logarithmic` graph axis option. * Resolve various trivial `go vet` issues. * Add a stream_group out parameter. * Remove incorrectly applied `Optional` attributes to the `circonus_account` resource. * Remove various `Optional` attributes from the `circonus_collector` data source. * Centralize the common need to suppress leading and trailing whitespace into `suppressWhitespace`. * Sync up with upstream vendor fixes for circonus_graph. * Update the checksum value for the http check. * Chase `circonus_graph`'s underlying `line_style` API object change from `string` to `*string`. * Clean up tests to use a generic terraform regression testing account. * Rename all identifiers that began with a `_` and replace with a corresponding lowercase glyph. * Remove stale comment in types. * Move the calls to `ResourceData`'s `SetId()` calls to be first in the list so that no resources are lost in the event of a `panic()`. * Remove `stateSet` from the `circonus_trigger` resource. * Remove `stateSet` from the `circonus_stream_group` resource. * Remove `schemaSet` from the `circonus_graph` resource. * Remove `stateSet` from the `circonus_contact` resource. * Remove `stateSet` from the `circonus_metric` resource. * Remove `stateSet` from the `circonus_account` data source. * Remove `stateSet` from the `circonus_collector` data source. * Remove stray `stateSet` call from the `circonus_contact` resource. This is an odd artifact to find... I'm completely unsure as to why it was there to begin with but am mostly certain it's a bug and needs to be removed. * Remove `stateSet` from the `circonus_check` resource. * Remove the `stateSet` helper function. All call sites have been converted to return errors vs `panic()`'ing at runtime. * Remove a pile of unused functions and type definitions. * Remove the last of the `attrReader` interface. * Remove an unused `Sprintf` call. * Update `circonus-gometrics` and remove unused files. * Document what `convertToHelperSchema()` does. Rename `castSchemaToTF` to `convertToHelperSchema`. Change the function parameter ordering so the `map` of attribute descriptions: this is much easier to maintain when the description map is first when creating schema inline. * Move descriptions into their respective source files. * Remove all instances of `panic()`. In the case of software bugs, log an error. Never `panic()` and always return a value. * Rename `stream_group` to `metric_cluster`. * Rename triggers to rule sets * Rename `stream` to `metric`. * Chase the `stream` -> `metric` change into the docs. * Remove some unused test functions. * Add the now required `color` attribute for graphing a `metric_cluster`. * Add a missing description to silence a warning. * Add `id` as a selector for the account data source. * Futureproof testing: Randomize all asset names to prevent any possible resource conflicts. This isn't a necessary change for our current build and regression testing, but *just in case* we have a radical change to our testing framework in the future, make all resource names fully random. * Rename various values to match the Circonus docs. * s/alarm/alert/g * Ensure ruleset criteria can not be empty.
2017-03-10 21:19:17 +01:00
---
layout: "circonus"
page_title: "Circonus: circonus_contact_group"
sidebar_current: "docs-circonus-resource-circonus_contact_group"
description: |-
Manages a Circonus Contact Group.
---
# circonus\_contact_group
The ``circonus_contact_group`` resource creates and manages a
[Circonus Contact Group](https://login.circonus.com/user/docs/Alerting/ContactGroups).
## Usage
```
resource "circonus_contact_group" "myteam-alerts" {
name = "MyTeam Alerts"
email {
user = "/user/1234"
}
email {
user = "/user/5678"
}
email {
address = "user@example.com"
}
http {
address = "https://www.example.org/post/endpoint"
format = "json"
method = "POST"
}
irc {
user = "/user/6331"
}
slack {
channel = "#myteam"
team = "T038UT13D"
}
sms {
user = "/user/1234"
}
sms {
address = "8005551212"
}
victorops {
api_key = "xxxx"
critical = 2
info = 5
team = "myteam"
warning = 3
}
xmpp {
user = "/user/9876"
}
aggregation_window = "5m"
alert_option {
severity = 1
reminder = "5m"
escalate_to = "/contact_group/4444"
}
alert_option {
severity = 2
reminder = "15m"
escalate_after = "2h"
escalate_to = "/contact_group/4444"
}
alert_option {
severity = 3
reminder = "24m"
escalate_after = "3d"
escalate_to = "/contact_group/4444"
}
}
```
## Argument Reference
* `aggregation_window` - (Optional) The aggregation window for batching up alert
notifications.
* `alert_option` - (Optional) There is one `alert_option` per severity, where
severity can be any number between 1 (high) and 5 (low). If configured, the
alerting system will remind or escalate alerts to further contact groups if an
alert sent to this contact group is not acknowledged or resolved. See below
for details.
* `email` - (Optional) Zero or more `email` attributes may be present to
dispatch email to Circonus users by referencing their user ID, or by
specifying an email address. See below for details on supported attributes.
* `http` - (Optional) Zero or more `http` attributes may be present to dispatch
[Webhook/HTTP requests](https://login.circonus.com/user/docs/Alerting/ContactGroups#WebhookNotifications)
by Circonus. See below for details on supported attributes.
* `irc` - (Optional) Zero or more `irc` attributes may be present to dispatch
IRC notifications to users. See below for details on supported attributes.
* `long_message` - (Optional) The bulk of the message used in long form alert
messages.
* `long_subject` - (Optional) The subject used in long form alert messages.
* `long_summary` - (Optional) The brief summary used in long form alert messages.
* `name` - (Required) The name of the contact group.
* `pager_duty` - (Optional) Zero or more `pager_duty` attributes may be present
to dispatch to
[Pager Duty teams](https://login.circonus.com/user/docs/Alerting/ContactGroups#PagerDutyOptions).
See below for details on supported attributes.
* `short_message` - (Optional) The subject used in short form alert messages.
* `short_summary` - (Optional) The brief summary used in short form alert
messages.
* `slack` - (Optional) Zero or more `pager_duty` attributes may be present to
dispatch to Pager Duty teams. See below for details on supported attributes.
* `sms` - (Optional) Zero or more `sms` attributes may be present to dispatch
SMS messages to Circonus users by referencing their user ID, or by specifying
an SMS Phone Number. See below for details on supported attributes.
* `tags` - (Optional) A list of tags attached to the Contact Group.
* `victorops` - (Optional) Zero or more `victorops` attributes may be present
to dispatch to
[VictorOps teams](https://login.circonus.com/user/docs/Alerting/ContactGroups#VictorOps).
See below for details on supported attributes.
## Supported Contact Group `alert_option` Attributes
* `escalate_after` - (Optional) How long to wait before escalating an alert that
is received at a given severity.
* `escalate_to` - (Optional) The Contact Group ID who will receive the
escalation.
* `reminder` - (Optional) If specified, reminders will be sent after a user
configurable number of minutes for open alerts.
* `severity` - (Required) An `alert_option` must be assigned to a given severity
level. Valid severity levels range from 1 (highest severity) to 5 (lowest
severity).
## Supported Contact Group `email` Attributes
Either an `address` or `user` attribute is required.
* `address` - (Optional) A well formed email address.
* `user` - (Optional) An email will be sent to the email address of record for
the corresponding user ID (e.g. `/user/1234`).
A `user`'s email address is automatically maintained and kept up to date by the
recipient, whereas an `address` provides no automatic layer of indirection for
keeping the information accurate (including LDAP and SAML-based authentication
mechanisms).
## Supported Contact Group `http` Attributes
* `address` - (Required) URL to send a webhook request to.
* `format` - (Optional) The payload of the request is a JSON-encoded payload
when the `format` is set to `json` (the default). The alternate payload
encoding is `params`.
* `method` - (Optional) The HTTP verb to use when making a request. Either
`GET` or `POST` may be specified. The default verb is `POST`.
## Supported Contact Group `irc` Attributes
* `user` - (Required) When a user has configured IRC on their user account, they
will receive an IRC notification.
## Supported Contact Group `pager_duty` Attributes
* `contact_group_fallback` - (Optional) If there is a problem contacting Pager
Duty, relay the notification automatically to the specified Contact Group
(e.g. `/contact_group/1234`).
* `service_key` - (Required) The Pager Duty Service Key.
* `webook_url` - (Required) The Pager Duty webhook URL that Pager Duty uses to
notify Circonus of acknowledged actions.
## Supported Contact Group `slack` Attributes
* `contact_group_fallback` - (Optional) If there is a problem contacting Slack,
relay the notification automatically to the specified Contact Group
(e.g. `/contact_group/1234`).
* `buttons` - (Optional) Slack notifications can have acknowledgement buttons
built into the notification message itself when enabled. Defaults to `true`.
* `channel` - (Required) Specify what Slack channel Circonus should send alerts
to.
* `team` - (Required) Specify what Slack team Circonus should look in for the
aforementioned `channel`.
* `username` - (Optional) Specify the username Circonus should advertise itself
as in Slack. Defaults to `Circonus`.
## Supported Contact Group `sms` Attributes
Either an `address` or `user` attribute is required.
* `address` - (Optional) SMS Phone Number to send a short notification to.
* `user` - (Optional) An SMS page will be sent to the phone number of record for
the corresponding user ID (e.g. `/user/1234`).
A `user`'s phone number is automatically maintained and kept up to date by the
recipient, whereas an `address` provides no automatic layer of indirection for
keeping the information accurate (including LDAP and SAML-based authentication
mechanisms).
## Supported Contact Group `victorops` Attributes
* `contact_group_fallback` - (Optional) If there is a problem contacting
VictorOps, relay the notification automatically to the specified Contact Group
(e.g. `/contact_group/1234`).
* `api_key` - (Required) The API Key for talking with VictorOps.
* `critical` - (Required)
* `info` - (Required)
* `team` - (Required)
* `warning` - (Required)
## Supported Contact Group `xmpp` Attributes
Either an `address` or `user` attribute is required.
* `address` - (Optional) XMPP address to send a short notification to.
* `user` - (Optional) An XMPP notification will be sent to the XMPP address of
record for the corresponding user ID (e.g. `/user/1234`).
## Import Example
`circonus_contact_group` supports importing resources. Supposing the following
Terraform:
```
provider "circonus" {
alias = "b8fec159-f9e5-4fe6-ad2c-dc1ec6751586"
}
resource "circonus_contact_group" "myteam" {
name = "My Team's Contact Group"
email {
address = "myteam@example.com"
}
slack {
channel = "#myteam"
team = "T024UT03C"
}
}
```
It is possible to import a `circonus_contact_group` resource with the following command:
```
$ terraform import circonus_contact_group.myteam ID
```
Where `ID` is the `_cid` or Circonus ID of the Contact Group
(e.g. `/contact_group/12345`) and `circonus_contact_group.myteam` is the name of
the resource whose state will be populated as a result of the command.