Giter Site home page Giter Site logo

rollbar / terraform-provider-rollbar Goto Github PK

View Code? Open in Web Editor NEW
25.0 19.0 13.0 8.65 MB

Terraform provider for Rollbar

Home Page: https://rollbar.com

License: MIT License

Makefile 1.24% Go 96.47% Shell 0.39% HCL 1.61% Dockerfile 0.30%
terraform rollbar

terraform-provider-rollbar's Introduction

Terraform provider for Rollbar

The Rollbar provider allows Terraform to control resources on Rollbar.com, the Continuous Code Improvement Platform.

The provider allows you to manage your Rollbar projects, tokens, users, teams and notifications with ease. It must be configured with the proper credentials before it can be used.

Status

Build & Test Coverage Status CodeQL Maintainability Test Coverage Go Report Card

Usage

Example usage:

# Install Rollbar provider from Terraform Registry
terraform {
  required_providers {
    rollbar = {
      source  = "rollbar/rollbar"
    }
  }
}

# Configure the Rollbar provider
provider "rollbar" {
  api_key = "YOUR_API_KEY" # read/write permissions needed
  project_api_key = "YOUR_PROJECT_API_KEY" # needed for notifications (read/write)
}

# Create a team
resource "rollbar_team" "frontend" {
  name = "frontend-team"
}

# Create a project and assign the team
resource "rollbar_project" "frontend" {
  name         = "react-frontend"
  team_ids = [rollbar_team.frontend.id]
}

# Create a new email notification rule for the "New Item" trigger
resource "rollbar_notification" "foo" {
  rule  {
    filters {
        type =  "environment"
        operation =  "neq"
        value = "production"
    }
    filters {
       type = "level"
       operation = "eq"
       value = "error"
    }
    trigger = "new_item"
  }
  channel = "email"
  config  {
    users = ["[email protected]"]
    teams = ["Owners"]
  }
}

# Create a new PagerDuty notification rule for >10 items in 60 minutes
resource "rollbar_notification" "bar" {
  rule  {
    filters {
        type = "rate"
        period = 60
        count = 10
    }
    trigger = occurrence_rate
  }
  channel = "pagerduty"
  config  {
   service_key = "TOKEN"
  }
}

# Create a new Slack notification rule for the "New Item" trigger
resource "rollbar_notification" "baz" {
  rule  {
    filters {
        type =  "environment"
        operation =  "eq"
        value = "production"
    }
    filters {
       type = "framework"
       operation = "eq"
       value = "13"
    }
    trigger = "new_item"
  }
  channel = "slack"
  config  {
     # message_template = optional
     show_message_buttons = true
     channel = "#demo-david"
  }
}
# Create a new Webhook notification rule for the "New Item" trigger
resource "rollbar_notification" "baz" {
  rule  {
    filters {
        type =  "environment"
        operation =  "eq"
        value = "production"
    }
    filters {
       type = "framework"
       operation = "eq"
       value = "13"
    }
    trigger = "new_item"
  }
  channel = "webhook"
  config  {
     url = "http://www.rollbar.com"
     format = "json"
  }
}

Note about framework filtering

When using the framework filter in notification rules, the correct value is a number (passed in as a string). The current list of framework values is available at https://docs.rollbar.com/docs/rql#framework-ids.

A copy of the list is shown below (last updated 9/15/2021):

{
    'unknown': 0,
    'rails': 1,
    'django': 2,
    'pyramid': 3,
    'node-js': 4,
    'pylons': 5,
    'php': 6,
    'browser-js': 7,
    'rollbar-system': 8,  # system messages, like "over rate limit"
    'android': 9,
    'ios': 10,
    'mailgun': 11,
    'logentries': 12,
    'python': 13,
    'ruby': 14,
    'sidekiq': 15,
    'flask': 16,
    'celery': 17,
    'rq': 18,
    'java': 19,
    'dotnet': 20,
    'go': 21,
    'react-native': 22,
    'macos': 23,
    'apex': 24,
    'spring': 25,
    'bottle': 26,
    'twisted': 27,
    'asgi': 28,
    'starlette': 29,
    'fastapi': 30,
    'karafka': 31,
    'flutter': 32,
}

See the docs for detailed usage information.

Debugging

Enable writing debug log to /tmp/terraform-provider-rollbar.log by setting an environment variable:

export TERRAFORM_PROVIDER_ROLLBAR_DEBUG=1
terraform apply   # or any command that calls the Rollbar provider

This is necessary because Terraform providers aren’t actually plugins - they don’t get loaded into the running Terraform process. Rather a provider is a stand alone program that is started as a child processes and communicates with Terraform via gRPC. Anything that child process writes to stdout/stderr is lost. So if we want debug logging we must write to a file.

Development

Requirements

  • Terraform 0.12.x, 0.13.x, or 0.14.x
  • Go 1.14.x, 1.15.x

See Quick Tests workflow for details of version compatibility testing.

Building locally

Run make build to build the provider from source.

Run make install to build from source then install the provider locally for usage by Terraform.

Folder ./example contains example Terraform configuration. To use this config with a locally built provider, copy file provider.tf.local to overwrite file provider.tf. Then run terraform init to initialize Terraform with the provider. See example configuration README for more detail.

Running make plan, make apply, or make destroy will:

  • Build the provider from your working directory, and install for local Terraform.
  • Setup Terraform configuration to use the freshly built provider
  • Run terraform <plan|apply|destroy> in the examples folder with debug logging enabled.
  • Display the logs on completion.

Testing

This provider includes both unit tests, and acceptance tests that run with a live Rollbar account.

To enable debug output when running tests:

$ export TERRAFORM_PROVIDER_ROLLBAR_DEBUG=1

To run the unit tests:

$ make test

To run the acceptance tests:

$ export ROLLBAR_API_KEY=<your API key>
$ make testacc

Continuous Delivery

We use semantic-release for continuous delivery. When a PR is merged into master the Semantic Release workflow is triggered. If relevant Conventional Commits annotations are found in the Git log, semantic-release creates a new release and calls GoReleaser to build the binaries.

This way no human is directly involved in the release process and the releases are guaranteed to be unromantic and unsentimental.

-- from the semantic-release docs

After a new release has been created by semantic-release, it may take up to 10 minutes for the provider binaries to be built and attached by GoReleaser.

Terraform Versions

Several Makefile targets build the provider inside a Docker container, then test it against different versions of Terraform. Environment variable ROLLBAR_API_KEY must be set.

  • make terraform012 - Terraform 0.12.x
  • make terraform013 - Terraform 0.13.x
  • make terraform014 - Terraform 0.14.x

License

This is Free Software, released under the terms of the MIT license.

History

Derived from babbel/terraform-provider-rollbar and jmcvetta/terraform-provider-rollbar

terraform-provider-rollbar's People

Contributors

bxsx avatar coryvirok avatar dbw0011 avatar dependabot-preview[bot] avatar dependabot[bot] avatar fmasuhr avatar graffzon avatar haggishunk avatar igayoso avatar ijsnow avatar jhottenstein avatar jmcvetta avatar jtsaito avatar mudetroit avatar nieblara avatar omicron7 avatar parabolic avatar pawelsz-rb avatar pawelsz1 avatar rjw1 avatar waltjones avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

terraform-provider-rollbar's Issues

Update project access token fails, but returns status `200 OK`

When trying to update a Rollbar project access token to use a different scope, status, or name than it was created with, the API returns status 200 OK indicating success. However subsequently listing the tokens shows no update was actually made.

If it is intentional that a token's scope, status, & name cannot be changed after creation, then the API should return status 400 Bad Request with a helpful error message. If this behavior is unintentional, then the API should update the token's record in the data store before returning 200 OK.

Example

jmcvetta@carbon:~/projects/terraform-provider-rollbar$ http PATCH https://api.rollbar.com/api/1/project/413779/access_token/055ab702454e40798fd22bdac249eb2e X-Rollbar-Access-Token:redacted status:='"disabled"'
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Alt-Svc: clear
Content-Length: 14
Content-Type: application/json; charset=utf-8
Date: Wed, 14 Oct 2020 14:04:50 GMT
Server: nginx/1.17.9
Via: 1.1 google
X-Rate-Limit-Limit: 5000
X-Rate-Limit-Remaining: 4997
X-Rate-Limit-Remaining-Seconds: 41
X-Rate-Limit-Reset: 1602684331
X-Response-Time: 101ms

{
    "err": 0
}


$ http GET https://api.rollbar.com/api/1/project/413779/access_tokens X-Rollbar-Access-Token:redacted  | head -18
{
  "err": 0,
  "result": [
    {
      "project_id": 413779,
      "access_token": "055ab702454e40798fd22bdac249eb2e",
      "name": "test-token",
      "status": "enabled",
      "rate_limit_window_size": null,
      "rate_limit_window_count": null,
      "cur_rate_limit_window_start": 1602684290,
      "cur_rate_limit_window_count": 0,
      "date_created": 1602683433,
      "date_modified": 1602684290,
      "scopes": [
        "read"
      ]
    },

Inconsistent shape of user data returned by list users and get user

A different set of fields is returned when listing all users versus getting a single user. The field email_enabled is only returned by the single user endpoint.

$ http GET https://api.rollbar.com/api/1/users X-Rollbar-Access-Token:redacted

{
    "err": 0,
    "result": {
        "users": [
            {
                "email": "[email protected]",
                "id": 238101,
                "username": "jmcvetta"
            }
        ]
    }
}


$ http GET https://api.rollbar.com/api/1/user/238101 X-Rollbar-Access-Token:redacted

{
    "err": 0,
    "result": {
        "email": "[email protected]",
        "email_enabled": 1,
        "id": 238101,
        "username": "jmcvetta"
    }
}

It would be better if both endpoints returned the same data shape for a user.

Also...

  • Since email_enabled is a boolean value, it would be nice if the API returned a bool rather than a number.
  • List users returns a users key under result. Most other Rollbar API list functions (that I've looked at so far) return the list itself as result.

Eliminate `go-model` dependency

If possible we should eliminate the dependency on go-model. It can potentially throw errors in a way that's hard to account for in unit tests. And the library is not very widely used, so its long term maintenance is a risk factor.

Use env var `ROLLBAR_API_KEY` instead of `ROLLBAR_APIKEY`

The babbel provider code can read the API key from environment variable ROLLBAR_APIKEY. That variable name is non-standard and doesn't match the field name in Terraform, api_key.

Therefore I will change the code to look for the API key in environment variable ROLLBAR_API_KEY.

Notifying @parabolic, @jtsaito, and @fmasuhr so there will be no surprises on the next release.

API documentation shows incomplete path

The API documentation for Get a team does not show the complete URL path needed to retrieve a team resource. The doc mentions team_id as a required path parameter, but does not show it in the example URL path.

image

Reconcile API-only team properties with UI

From the API docs:

standard is the only access level you can choose in the UI.

light and view are API-only team access levels. light gives the team read and write access, but not to all settings. view gives the team read-only access.

I'm a little concerned about this, since the UI and the API may have different logic on the backend. @mrunalk is it safe to use these API-only team access levels?

Allow creation of notifications using account access token

As pointed out by @jtsaito in #31, creating a notification currently requires a project access token, not an account access token.

This makes it difficult for Terraform to control notifications. The ROLLBAR_API_KEY used for API authentication is a local secret, not something that should for every different API call. It's not impossible, but it would be pretty weird & non-standard.

It seems better for this action to require a project access token with write scope or an account access token with write scope.

@mrunalk @coryvirok your thoughts?

More than one token per project can have the same name

The API allows creation of more than one token per project with the same name. This is potentially confusing, and probably a bug.

$ http POST https://api.rollbar.com/api/1/project/415372/access_tokens X-Rollbar-Access-Token:redacted name:='"foobar"' scopes:='["read"]' status:='"enabled"' 
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Alt-Svc: clear
Content-Length: 420
Content-Type: application/json; charset=utf-8
Date: Mon, 19 Oct 2020 08:33:56 GMT
Server: nginx/1.17.9
Via: 1.1 google
X-Rate-Limit-Limit: 5000
X-Rate-Limit-Remaining: 4999
X-Rate-Limit-Remaining-Seconds: 60
X-Rate-Limit-Reset: 1603096495
X-Response-Time: 55ms

{
    "err": 0,
    "result": {
        "access_token": "7f6b30a1fb91485da233f52d0dca6302",
        "cur_rate_limit_window_count": 0,
        "cur_rate_limit_window_start": 1603096436,
        "date_created": 1603096436,
        "date_modified": 1603096436,
        "name": "foobar",
        "project_id": 415372,
        "rate_limit_window_count": null,
        "rate_limit_window_size": null,
        "scopes": [
            "read"
        ],
        "status": "enabled"
    }
}

$ http POST https://api.rollbar.com/api/1/project/415372/access_tokens X-Rollbar-Access-Token:redacted name:='"foobar"' scopes:='["read"]' status:='"enabled"' 
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Alt-Svc: clear
Content-Length: 420
Content-Type: application/json; charset=utf-8
Date: Mon, 19 Oct 2020 08:34:03 GMT
Server: nginx/1.17.9
Via: 1.1 google
X-Rate-Limit-Limit: 5000
X-Rate-Limit-Remaining: 4998
X-Rate-Limit-Remaining-Seconds: 52
X-Rate-Limit-Reset: 1603096495
X-Response-Time: 58ms

{
    "err": 0,
    "result": {
        "access_token": "60b1cdbcdab340cca569ac48ae50f378",
        "cur_rate_limit_window_count": 0,
        "cur_rate_limit_window_start": 1603096443,
        "date_created": 1603096443,
        "date_modified": 1603096443,
        "name": "foobar",
        "project_id": 415372,
        "rate_limit_window_count": null,
        "rate_limit_window_size": null,
        "scopes": [
            "read"
        ],
        "status": "enabled"
    }
}

Does it make sense to expose current rate limit info?

Does it even make sense for the Terraform provider to expose cur_rate_limit_window_count and cur_rate_limit_window_start as attributes on a rollbar_project_access_token resource? These values should change constantly - so I don't see how they would be useful as Terraform outputs. If anything, their presence as resource attributes may be confusing.

@coryvirok @mrunalk what are your thoughts?

Successful API create operations should return HTTP 201

Currently the API operations to create new Projects and Teams (and probably other entities) return HTTP status 200 OK on success. However as create operations they should instead return status 201 Created on success.

See 200 OK vs 201 Created for comparison.

Confirmed to affect:

  • Project
  • Project Access Token
  • Team

Unexpected `from_user_id` on invitations created through API

When I create a team invitation through the web UI, that invitation shows my correct Rollbar user ID in the from_user_id field. However when I create an invitation through the API, it shows a different user ID (that does not belong to me).

It looks like maybe the invitation is recorded as coming from a special "API User" account, rather than the account that owns the token that authorized the API call.

# My user ID
$ http GET https://api.rollbar.com/api/1/users X-Rollbar-Access-Token:redacted

{
    "err": 0,
    "result": {
        "users": [
            {
                "email": "[email protected]",
                "id": 238101,
                "username": "jmcvetta"
            }
        ]
    }
}


# Invitation that was created through web UI
$ http GET https://api.rollbar.com/api/1/team/676971/invites X-Rollbar-Access-Token:redacted

{
    "err": 0,
    "result": [
        {
            "date_created": 1603192170,
            "date_redeemed": null,
            "from_user_id": 238101,
            "id": 153649,
            "status": "pending",
            "team_id": 676971,
            "to_email": "[email protected]"
        }
    ]
}


# Invitation created through the API
$ http POST https://api.rollbar.com/api/1/team/676971/invites X-Rollbar-Access-Token:redacted email:='"[email protected]"'

{
    "err": 0,
    "result": {
        "date_created": 1603192477,
        "date_redeemed": null,
        "from_user_id": 5325,
        "id": 153650,
        "status": "pending",
        "team_id": 676971,
        "to_email": "[email protected]"
    }
}

Add metadata to schema

Terraform SDK v2 (which we're already using) added support for metadata on resources and fields. This is not yet actually used by Terraform for anything, but will be used in a future version. So we ought to add this now.

it’s recommended that you set these properties to whatever you’d document the resource or field as in your terraform.io docs for the resource.

Todo

  • resource rollbar_project
  • resource rollbar_projec_access_token
  • resource rollbar_team
  • resource rollbar_user
  • data source rollbar_project
  • data source rollbar_projects
  • data source rollbar_project_access_token
  • data source rollbar_project_access_tokens

API support for deleting project access token

Currently the API does not support deleting a project access token. This functionality is required for the Terraform provider to manage project access tokens.

$ http DELETE https://api.rollbar.com/api/1/project/411334/access_token/d6d4b456f72048dfb8a933afe3ac66f6 X-Rollbar-Access-Token:redacted
HTTP/1.1 404 Not Found
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Alt-Svc: clear
Content-Length: 40
Content-Type: application/json; charset=utf-8
Date: Tue, 06 Oct 2020 11:48:58 GMT
Server: nginx/1.17.9
Via: 1.1 google
X-Response-Time: 1ms

{
    "err": 1,
    "message": "not found"
}

API error when creating token with `rate_limit_window_size` specified

Trying to specify a rate_limit_window_size when creating a project access token, the API returns the following strange error:

$ http POST https://api.rollbar.com/api/1/project/415372/access_tokens X-Rollbar-Access-Token:redacted name:='"bar"' scopes:='["read"]' status:='"enabled"' rate_limit_window_size=60
HTTP/1.1 400 Bad Request
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Alt-Svc: clear
Content-Length: 99
Content-Type: application/json; charset=utf-8
Date: Mon, 19 Oct 2020 07:07:36 GMT
Server: nginx/1.17.9
Via: 1.1 google
X-Rate-Limit-Limit: 5000
X-Rate-Limit-Remaining: 4999
X-Rate-Limit-Remaining-Seconds: 60
X-Rate-Limit-Reset: 1603091316
X-Response-Time: 41ms

{
    "err": 1,
    "message": "u'60' is not one of [0, 60, 300, 1800, 3600, 86400, 604800, 2592000]"
}

However if I first create a token without specifying rate_limit_window_size, calling PATCH on that token does successfully update rate_limit_window_size.

$ http PATCH https://api.rollbar.com/api/1/project/415372/access_token/972e844d22934f94a044e6e775a5cf55 X-Rollbar-Access-Token:redacted rate_limit_window_size:=60
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Alt-Svc: clear
Content-Length: 14
Content-Type: application/json; charset=utf-8
Date: Mon, 19 Oct 2020 07:16:54 GMT
Server: nginx/1.17.9
Via: 1.1 google
X-Rate-Limit-Limit: 5000
X-Rate-Limit-Remaining: 4997
X-Rate-Limit-Remaining-Seconds: 19
X-Rate-Limit-Reset: 1603091833
X-Response-Time: 76ms

{
    "err": 0
}

Example config for babbel provider

Hi @parabolic, @jtsaito, and @fmasuhr! I'm the developer Rollbar hired to build out the Terraform provider. Thanks for writing the provider up to this point!

I want to make sure future versions of the provider don't break your Terraform configurations. (Or if they do break them, we'll have discussed it well in advance of the release.) So it would be super helpful if you could give me some example configurations illustrating how you currently use the provider.

I'll add a new check to the automated testing workflow. To see if terraform plan works okay with your example configs. This will help ensure that the provider schemas remain compatible with your existing configurations.

Project Settings

Add support for Rollbar project settings.

Per the spec, as of 6 Oct 2020 the API may not yet support all project settings.

API returns deleted projects

After deleting a project through the API, it still shows up in the list of projects returned by the API - only with its name set to nil. This seemingly undesirable behavior should be fixed on the API side. We work around it by removing any result with an empty name.

This does not seem like desirable behavior for the API. Once a project has been deleted, the API should not include it in the list or projects.

`id` field for project access token

Currently the API uses the access token itself is used as the identifier for a project access token object. This is undesirable, as the token may be exposed in intermediary HTTP logs, as well as in debug logs.

Instead the API should expose a standard integer id field to identify PAT objects.

Test handling of invalid Terraform configuration

The provider should fail gracefully if the user provides invalid configuration.

E.g. the user specifies a non-existent scope:

# Terraform should fail on this resource, with a helpful error message.
resource "rollbar_project_access_token" "foo" {
    name = "test-token"
    project_id = 12345
    scopes = [
        # There is no valid scope named "avocado"
        "avocado"
    ]
}

Correct handling of bad configuration must be tested. This is not covered in Terraform docs; need to research best practices.

API returns `403 Forbidden` when team or project not found

When trying to read a team with an ID that doesn't exist, the API returns status 403 Forbidden. Instead it should return 404 Not Found.

$ http GET https://api.rollbar.com/api/1/team/9999999999 X-Rollbar-Access-Token:redacted
HTTP/1.1 403 Forbidden
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Alt-Svc: clear
Content-Length: 62
Content-Type: application/json; charset=utf-8
Date: Mon, 26 Oct 2020 06:53:39 GMT
ETag: "1635533788"
Server: nginx/1.17.9
Via: 1.1 google
X-Rate-Limit-Limit: 5000
X-Rate-Limit-Remaining: 4998
X-Rate-Limit-Remaining-Seconds: 23
X-Rate-Limit-Reset: 1603695242
X-Response-Time: 13ms

{
    "err": 1,
    "message": "Team not found in this account."
}

API docs: possible typo in scopes

The API docs show four possible scopes for a project access token: write, read, post_server_item, and post_client_server. Yet actual output of the API has post_client_item instead of post_client_server. This is is probably a typo in the API docs.

image

From the actual JSON response from API:

        {
            "access_token": "da62bed0067d4bfab7a2d91e8fcc4eb3",
            "cur_rate_limit_window_count": null,
            "cur_rate_limit_window_start": null,
            "date_created": 1602085340,
            "date_modified": 1602085340,
            "name": "post_client_item",
            "project_id": 411703,
            "rate_limit_window_count": null,
            "rate_limit_window_size": null,
            "scopes": [
                "post_client_item"
            ],
            "status": "enabled"
        }

Catch `401 Unauthorized` and return custom error

Potentially Rollbar API could return 401 Unauthorized because we're using bad credentials. RollbarApiClient does not currently catch this. But it should, and return a custom error type ErrUnauthorized. Then the provider can interpret that result and give a friendly error message.

  • Project
  • Team
  • Project access token

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.