Coder Social home page Coder Social logo

fastly / terraform-provider-fastly Goto Github PK

View Code? Open in Web Editor NEW
116.0 40.0 133.0 26.41 MB

Terraform Fastly provider

Home Page: https://www.terraform.io/docs/providers/fastly/

License: Mozilla Public License 2.0

Makefile 0.34% Go 99.07% Shell 0.23% HCL 0.36%
terraform terraform-provider plugin fastly-oss-tier1

terraform-provider-fastly's Introduction

Fastly Terraform Provider

Requirements

  • Terraform 0.12.x or higher
  • Go 1.20 (to build the provider plugin)

NOTE: the last version of the Fastly provider to support Terraform 0.11.x and below was v0.26.0

Building The Provider

Clone repository to: $GOPATH/src/github.com/fastly/terraform-provider-fastly

$ mkdir -p $GOPATH/src/github.com/fastly; cd $GOPATH/src/github.com/fastly
$ git clone [email protected]:fastly/terraform-provider-fastly

Enter the provider directory and build the provider

$ cd $GOPATH/src/github.com/fastly/terraform-provider-fastly
$ make build

Developing the Provider

If you wish to work on the provider, you'll first need Go installed on your machine (version 1.20+ is required).

To compile the provider, run make build. This will build the provider and put the provider binary in a local bin directory.

$ make build
...

Alongside the newly built binary a file called developer_overrides.tfrc will be created. The make build target will communicate back details for setting the TF_CLI_CONFIG_FILE environment variable that will enable Terraform to use your locally built provider binary.

NOTE: If you have issues seeing any behaviours from code changes you've made to the provider, then it might be the terraform CLI is getting confused by which provider binary it should be using. Check inside the ./bin/ directory to see if there are multiple providers with different commit hashes (e.g. terraform-provider-fastly_v2.2.0-5-gfdc37cee) and delete them first before running make build. This should help the Terraform CLI resolve to the correct binary.

Debugging the provider

The previous method with dev_overrides should be sufficient for most development use including testing your local changes with actual Terraform code. However, sometimes it can be helpful to run the provider in debug mode if you need to attach a debugger like delve to solve a particular issue.

The way Terraform normally works is that it starts the provider in a subprocess and connects to it using GRPC over a local socket. (For more information on this, see hashicorp/go-plugin). For debugging, it is possible to bypass this and execute the provider in a separate process, then tell Terraform how to communicate with it. The benefit of this is that the provider can be launched with a debugger attached in the same way that the debugger would attach to any normal executable.

There are a few ways to do this depending on which debugger is being used, but we will use delve here as the process should be pretty similar for other debuggers. The two things that need to be configured are that the provider is compiled without optimisations, and the executable is run with the --debug flag. Compiling without optimisations ensures that the debugger can access all of the symbols in the binary that it needs to, and the --debug flag tells the Terraform plugin SDK to expect to be run in its own process, and to display the instructions for connecting to it after it starts up.

With delve this can be done in a single command:

$ dlv debug . -- --debug
Type 'help' for list of commands.
(dlv) continue
{"@level":"debug","@message":"plugin address","@timestamp":"2021-03-26T12:10:13.320981Z","address":"/var/folders/qm/swg2hf4h5t8sdht8yhds4dg6m0000gn/T/plugin865249851","network":"unix"}
Provider started, to attach Terraform set the TF_REATTACH_PROVIDERS env var:

        TF_REATTACH_PROVIDERS='{"fastly/fastly":{"Protocol":"grpc","Pid":54132,"Test":true,"Addr":{"Network":"unix","String":"/var/folders/qm/swg2hf4h5t8sdht8yhds4dg6m0000gn/T/plugin865249851"}}}'

This can also be done in two separate steps. The -gcflags disables optimisations (-N) and inlining (-l).

$ go build -gcflags="all=-N -l" -o terraform-provider-fastly_debug
$ dlv exec terraform-provider-fastly_debug -- --debug

As the message instructs, go to another shell and export the TF_REATTACH_PROVIDERS environment variable. Then use Terraform as usual, and it will automatically use the provider in the debugger.

$ export TF_REATTACH_PROVIDERS='{"fastly/fastly":{"Protocol":"grpc","Pid":54132,"Test":true,"Addr":{"Network":"unix","String":"/var/folders/qm/swg2hf4h5t8sdht8yhds4dg6m0000gn/T/plugin865249851"}}}'
$ terraform plan

You will then be able to set breakpoints and trace the provider's execution using the debugger as you would expect.

The implementation for setting up debug mode presumes Terraform 0.13.x is being used. If you're using Terraform 0.12.x you'll need to manually modify the value assigned to TF_REATTACH_PROVIDERS so that the key "fastly/fastly" becomes "registry.terraform.io/-/fastly". See HashiCorp's "Support for Debuggable Provider Binaries" for more details.

Summary

(first shell)  dlv debug . --headless -- --debug
(second shell) dlv connect <output from first shell>
               continue
               <Ctrl-c>
               break fastly/block_fastly_service_package.go:123
(third shell)  export TF_REATTACH_PROVIDERS="..."
               terraform apply
(second shell) continue (do your step debugging)
               <Ctrl-c> (then run another terraform command from third shell)

Testing

In order to test the provider, you can simply run make test.

$ make test

In order to run the full suite of Acceptance tests, run make testacc.

Note: Acceptance tests create real resources, and often cost money to run. You should expect that the full acceptance test suite will take hours to run.

$ make testacc

In order to run an individual acceptance test, the '-run' flag can be used together with a regular expression. The following example uses a regular expression matching single test called 'TestAccFastlyServiceVCL_basic'.

$ make testacc TESTARGS='-run=TestAccFastlyServiceVCL_basic'

The following example uses a regular expression to execute a grouping of basic acceptance tests.

$ make testacc TESTARGS='-run=TestAccFastlyServiceVCL.*_basic'

In order to run the tests with extra debugging context, prefix the make command with TF_LOG (see the terraform documentation for details).

$ TF_LOG=trace make testacc

By default, the tests run with a parallelism of 4. This can be reduced if some tests are failing due to network-related issues, or increased if possible, to reduce the running time of the tests. Prefix the make command with TEST_PARALLELISM, as in the following example, to configure this.

$ TEST_PARALLELISM=8 make testacc

Depending on the Fastly account used, some features may not be enabled (e.g. Platform TLS). This may result in some tests failing, potentially with 403 Unauthorised errors, when the full test suite is being run. Check the Fastly API documentation to confirm if the failing tests use features in Limited Availability or only available to certain customers. If this is the case, either use the TESTARGS regular expressions described above, or temporarily add t.SkipNow() to the top of any tests that should be excluded.

Building The Documentation

The documentation is built from components (go templates) stored in the templates folder. Building the documentation copies the full markdown into the docs folder, ready for deployment to Hashicorp.

NOTE: you'll need the tfplugindocs tool for generating the Markdown to be deployed to Hashicorp. For more information on generating documentation, refer to https://www.terraform.io/docs/registry/providers/docs.html

  • To validate the /template directory structure:
make validate-docs
  • To build the /docs documentation Markdown files:
make generate-docs

Contributing

Refer to CONTRIBUTING.md

terraform-provider-fastly's People

Contributors

agilgur5 avatar annez avatar appilon avatar bengesoff avatar catsby avatar chenrui333 avatar dbeckham avatar dependabot[bot] avatar ezkl avatar grubernaut avatar guyrichardson-ockl avatar integralist avatar kellymclaughlin avatar lanej avatar matpimenta avatar mccurdyc avatar msuterski avatar oscardovao avatar phamann avatar philippschulte avatar radeksimko avatar sbfaulkner avatar smaeda-ks avatar spheromak avatar stack72 avatar thommahoney avatar travertischio avatar trentrosenbaum avatar yawn avatar yoink00 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  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  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  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  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

terraform-provider-fastly's Issues

gzip should use default extensions and content_types

Terraform Version

v0.10.7

Affected Resource(s)

Please list the resources as a list, for example:

  • fastly_service_v1

Terraform Configuration Files

resource "fastly_service_v1" "service" {
...
  gzip {
    name = "gzip_settings"
  }
}

Expected Behavior

If in a gzip block you don't provide extensions and content_types, which are listed as optional, you should get the defaults as described in https://docs.fastly.com/guides/basic-configuration/enabling-automatic-gzipping, not nothing. The Fastly API reference also says of these fields: "If you omit this field a default list will be used."

Actual Behavior

If you don't include extensions and content_types, Fastly produces this VCL (notice the regexes):

if ((beresp.status == 200 || beresp.status == 404) && (beresp.http.content-type ~ "^()\s*($|;)" || req.url ~ "\.()($|\?)" ) ) {

Wrong documentation on cache_settings / action in Fastly provider

This issue was originally opened by @blinohod as hashicorp/terraform#15519. It was migrated here as a result of the provider split. The original body of the issue is below.


Hello,

Accordingly to documentation:
https://www.terraform.io/docs/providers/fastly/r/service_v1.html#cache_setting

action - (Required) One of cache, pass, or restart, as defined on Fastly's documentation under "Caching action descriptions".

However in fact this field is optional and it's relevant use-case when it shouldn't be set.

FASTLY PLUGIN requires FASTLY_API_KEY set on workstation even when FASTLY_API_KEY env variable set in atlas

This issue was originally opened by @neillturner as hashicorp/terraform#8156. It was migrated here as part of the provider split. The original body of the issue is below.


Fastly requires an api key to be specified to access the fastly api.
you can specify this as an environment variable FASTLY_API_KEY which is obviously
preferable as then you don't have to put the value in the terraform code.

when you run terraform with the remote option and atlas you can set the environment variable FASTLY_API_KEY in atalas.

however if you don't first set it on your workstation before calling terraform like this
export FASTLY_API_KEY="fakekey"
then you get error api_key not set.
You should not need to do this.

With the AWS provider you can set the environment variables

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY 

in atlas
and you don't have to set the environment variables to some faske value before running terraform remote
on your workstation. I gues the AWS providers check wher ethe environment variable is set in atlas.

Terraform Version 0.6.16

Affected Resource(s)

provider "fastly"  
resource "fastly_service_v1"

Terraform Configuration Files

just create a fastly service without specifying a provider

resource "fastly_service_v1" "demo" {
  name = "demofastly"

  domain {
    name    = "demo.notexample.com"
    comment = "demo"
  }

  backend {
    address = "127.0.0.1"
    name    = "localhost"
    port    = 80
  }

  force_destroy = true
}

Debug Output

gives a message saying fastly provider api_key doesn't have a value.

Expected Behavior

it should check that atlas has the env variable FASTLY_API_KEY and if so not require the default value

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  • Setup a terraform file as above.
  • Run terraform
terraform remote config 
terraform push
  • in atlas set the env variable FASTLY_API_KEY

Workaround

before running terraform

export FASTLY_API_KEY="fakekey"

provider/fastly: Allow specifying log format version for Papertrail provider

This issue was originally opened by @acme as hashicorp/terraform#12462. It was migrated here as part of the provider split. The original body of the issue is below.


Terraform Version

Terraform v0.8.8

Affected Resource(s)

Please list the resources as a list, for example:

  • fastly

Terraform Configuration Files

# Configure the Fastly Provider
provider "fastly" {
  api_key = "${var.fastly_api_key}"
}

# Create a Service
resource "fastly_service_v1" "myservice" {
  name = "${var.domain}"

  domain {
    name = "${var.domain}"
  }

  default_ttl   = 10
  force_destroy = true

  vcl {
    name    = "main.vcl"
    main    = "true"
    content = "${file("files/main.vcl")}"
  }

  papertrail {
    name               = "Papertrail"
    format             = "%h %l %u %{now}V %{req.request}V %{req.url}V %>s"
    address            = "${var.papertrail_address}"
    port               = "${var.papertrail_port}"
    format_version     = 2
  }
}

Debug Output

https://gist.githubusercontent.com/acme/276edaf056a0e7c874341c7e6e454893/raw/5bdb0c435dce00a4070e41ede7226393f2d9be9c/gistfile1.txt

Panic Output

Expected Behavior

Terraform created a Fastly Papertrail logging configuration with log format version 2.

Actual Behavior

* fastly_service_v1.myservice: papertrail.0: invalid or unknown key: format_version

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform apply

Important Factoids

References

Healthchecks don't seem to be saved in state?

Terraform version
0.10.0

When you run terraform plan right after a terraform apply, the expected output is that there would be no changes. But you end up with changes relating to just the healthchecks.

Below is what happens when you run terraform plan > terraform apply > terraform plan

terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

fastly_service_v1.fastly-staging-prod-www: Refreshing state... (ID: someID)
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

~ fastly_service_v1.fastly-staging-prod-www
    healthcheck.1180178182.check_interval:    "5000" => "0"
    healthcheck.1180178182.expected_response: "200" => "0"
    healthcheck.1180178182.host:              "www.example.com" => ""
    healthcheck.1180178182.http_version:      "1.1" => ""
    healthcheck.1180178182.initial:           "2" => "0"
    healthcheck.1180178182.method:            "HEAD" => ""
    healthcheck.1180178182.name:              "www.example.com-healthcheck" => ""
    healthcheck.1180178182.path:              "/" => ""
    healthcheck.1180178182.threshold:         "3" => "0"
    healthcheck.1180178182.timeout:           "500" => "0"
    healthcheck.1180178182.window:            "5" => "0"
    healthcheck.3887188747.check_interval:    "" => "5000"
    healthcheck.3887188747.expected_response: "" => "200"
    healthcheck.3887188747.host:              "" => "www.example.com"
    healthcheck.3887188747.http_version:      "" => "1.1"
    healthcheck.3887188747.initial:           "" => "2"
    healthcheck.3887188747.method:            "" => "HEAD"
    healthcheck.3887188747.name:              "" => "www.example.com-healthcheck"
    healthcheck.3887188747.path:              "" => ""
    healthcheck.3887188747.threshold:         "" => "3"
    healthcheck.3887188747.timeout:           "" => "500"
    healthcheck.3887188747.window:            "" => "5"
    healthcheck.4261511046.check_interval:    "5000" => "0"
    healthcheck.4261511046.expected_response: "200" => "0"
    healthcheck.4261511046.host:              "www.example2.com" => ""
    healthcheck.4261511046.http_version:      "1.1" => ""
    healthcheck.4261511046.initial:           "2" => "0"
    healthcheck.4261511046.method:            "HEAD" => ""
    healthcheck.4261511046.name:              "www.example2.com-healthcheck" => ""
    healthcheck.4261511046.path:              "/" => ""
    healthcheck.4261511046.threshold:         "3" => "0"
    healthcheck.4261511046.timeout:           "500" => "0"
    healthcheck.4261511046.window:            "5" => "0"
    healthcheck.58475580.check_interval:      "" => "5000"
    healthcheck.58475580.expected_response:   "" => "200"
    healthcheck.58475580.host:                "" => "www.example2.com"
    healthcheck.58475580.http_version:        "" => "1.1"
    healthcheck.58475580.initial:             "" => "2"
    healthcheck.58475580.method:              "" => "HEAD"
    healthcheck.58475580.name:                "" => "www.example2.com-healthcheck"
    healthcheck.58475580.path:                "" => ""
    healthcheck.58475580.threshold:           "" => "3"
    healthcheck.58475580.timeout:             "" => "500"
    healthcheck.58475580.window:              "" => "5"


Plan: 0 to add, 1 to change, 0 to destroy.
terraform apply
fastly_service_v1.fastly-staging-prod-www: Refreshing state... (ID: someID)
fastly_service_v1.fastly-staging-prod-www: Modifying... (ID: someID)
  healthcheck.1180178182.check_interval:    "5000" => "0"
  healthcheck.1180178182.expected_response: "200" => "0"
  healthcheck.1180178182.host:              "www.example.com" => ""
  healthcheck.1180178182.http_version:      "1.1" => ""
  healthcheck.1180178182.initial:           "2" => "0"
  healthcheck.1180178182.method:            "HEAD" => ""
  healthcheck.1180178182.name:              "www.example.com-healthcheck" => ""
  healthcheck.1180178182.path:              "/" => ""
  healthcheck.1180178182.threshold:         "3" => "0"
  healthcheck.1180178182.timeout:           "500" => "0"
  healthcheck.1180178182.window:            "5" => "0"
  healthcheck.3887188747.check_interval:    "" => "5000"
  healthcheck.3887188747.expected_response: "" => "200"
  healthcheck.3887188747.host:              "" => "www.example.com"
  healthcheck.3887188747.http_version:      "" => "1.1"
  healthcheck.3887188747.initial:           "" => "2"
  healthcheck.3887188747.method:            "" => "HEAD"
  healthcheck.3887188747.name:              "" => "www.example.com-healthcheck"
  healthcheck.3887188747.path:              "" => ""
  healthcheck.3887188747.threshold:         "" => "3"
  healthcheck.3887188747.timeout:           "" => "500"
  healthcheck.3887188747.window:            "" => "5"
  healthcheck.4261511046.check_interval:    "5000" => "0"
  healthcheck.4261511046.expected_response: "200" => "0"
  healthcheck.4261511046.host:              "www.example2.com" => ""
  healthcheck.4261511046.http_version:      "1.1" => ""
  healthcheck.4261511046.initial:           "2" => "0"
  healthcheck.4261511046.method:            "HEAD" => ""
  healthcheck.4261511046.name:              "www.example2.com-healthcheck" => ""
  healthcheck.4261511046.path:              "/" => ""
  healthcheck.4261511046.threshold:         "3" => "0"
  healthcheck.4261511046.timeout:           "500" => "0"
  healthcheck.4261511046.window:            "5" => "0"
  healthcheck.58475580.check_interval:      "" => "5000"
  healthcheck.58475580.expected_response:   "" => "200"
  healthcheck.58475580.host:                "" => "www.example2.com"
  healthcheck.58475580.http_version:        "" => "1.1"
  healthcheck.58475580.initial:             "" => "2"
  healthcheck.58475580.method:              "" => "HEAD"
  healthcheck.58475580.name:                "" => "www.example2.com-healthcheck"
  healthcheck.58475580.path:                "" => ""
  healthcheck.58475580.threshold:           "" => "3"
  healthcheck.58475580.timeout:             "" => "500"
  healthcheck.58475580.window:              "" => "5"
fastly_service_v1.fastly-staging-prod-www: Still modifying... (ID: someID, 10s elapsed)
fastly_service_v1.fastly-staging-prod-www: Modifications complete (ID: someID)

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path: 
terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

fastly_service_v1.fastly-staging-prod-www: Refreshing state... (ID: someID)
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

~ fastly_service_v1.fastly-staging-prod-www
    healthcheck.1180178182.check_interval:    "5000" => "0"
    healthcheck.1180178182.expected_response: "200" => "0"
    healthcheck.1180178182.host:              "www.example.com" => ""
    healthcheck.1180178182.http_version:      "1.1" => ""
    healthcheck.1180178182.initial:           "2" => "0"
    healthcheck.1180178182.method:            "HEAD" => ""
    healthcheck.1180178182.name:              "www.example.com-healthcheck" => ""
    healthcheck.1180178182.path:              "/" => ""
    healthcheck.1180178182.threshold:         "3" => "0"
    healthcheck.1180178182.timeout:           "500" => "0"
    healthcheck.1180178182.window:            "5" => "0"
    healthcheck.3887188747.check_interval:    "" => "5000"
    healthcheck.3887188747.expected_response: "" => "200"
    healthcheck.3887188747.host:              "" => "www.example.com"
    healthcheck.3887188747.http_version:      "" => "1.1"
    healthcheck.3887188747.initial:           "" => "2"
    healthcheck.3887188747.method:            "" => "HEAD"
    healthcheck.3887188747.name:              "" => "www.example.com-healthcheck"
    healthcheck.3887188747.path:              "" => ""
    healthcheck.3887188747.threshold:         "" => "3"
    healthcheck.3887188747.timeout:           "" => "500"
    healthcheck.3887188747.window:            "" => "5"
    healthcheck.4261511046.check_interval:    "5000" => "0"
    healthcheck.4261511046.expected_response: "200" => "0"
    healthcheck.4261511046.host:              "www.example2.com" => ""
    healthcheck.4261511046.http_version:      "1.1" => ""
    healthcheck.4261511046.initial:           "2" => "0"
    healthcheck.4261511046.method:            "HEAD" => ""
    healthcheck.4261511046.name:              "www.example2.com-healthcheck" => ""
    healthcheck.4261511046.path:              "/" => ""
    healthcheck.4261511046.threshold:         "3" => "0"
    healthcheck.4261511046.timeout:           "500" => "0"
    healthcheck.4261511046.window:            "5" => "0"
    healthcheck.58475580.check_interval:      "" => "5000"
    healthcheck.58475580.expected_response:   "" => "200"
    healthcheck.58475580.host:                "" => "www.example2.com"
    healthcheck.58475580.http_version:        "" => "1.1"
    healthcheck.58475580.initial:             "" => "2"
    healthcheck.58475580.method:              "" => "HEAD"
    healthcheck.58475580.name:                "" => "www.example2.com-healthcheck"
    healthcheck.58475580.path:                "" => ""
    healthcheck.58475580.threshold:           "" => "3"
    healthcheck.58475580.timeout:             "" => "500"
    healthcheck.58475580.window:              "" => "5"


Plan: 0 to add, 1 to change, 0 to destroy.

Domains do not support count, making variable interpolation impossible

Terraform Version

Terraform v0.11.2

  • provider.fastly v0.1.4

Affected Resource(s)

  • domain

Currently the Domain field does not support count, which makes variable interpolation very difficult. Our goal is to be able to specify a map of domains, depending on the environment (staging/prod), and retain the same config between both envs. Since domains does not include count, it's rather difficult to perform this, as domains have to be specified explicitly, thus making the Fastly config non-reusuable.

An attempt at this would be:


resource "fastly_service_v1" "demo" {
  name = "demofastly"

  domain {
    name    = "${element(split(",", var.domains["domain"]), count.index)}"
    comment = "${element(split(",", var.domains["comment"]), count.index)}"
    count = "${length(var.domains)}"
  }

  backend {
    address = "127.0.0.1"
    name    = "localhost"
    port    = 80
  }

  force_destroy = true
}

See https://www.terraform.io/docs/configuration/resources.html#using-variables-with-count.

If anyone has any advice on a different method to have a single (or identical) config between staging and prod (two Fastly environments), just different listening domains, we would love it!

request_setting imports incorrectly

When I imported a request_setting and then ran a plan against it, it showed that parts of the request_setting started as false when they actually were unset / blank on Fastly ( "" ). Wasn't exactly sure where / what caused this problem so couldn't PR it myself

Terraform Version

v0.10.7

Affected Resource(s)

fastly_service_v1.request_setting, more specifically it would seem to be a problem importing (or updating?):

  • bypass_busy_wait
  • force_miss
  • force_ssl
  • geo_headers
  • timer_support

Expected Behavior

I terraform import a request_setting that has those 5 unset / blank. I run a terraform plan and it says they began as "".

Actual Behavior

I terraform imported a request_setting that had those 5 unset / blank. When I ran a terraform plan it said they began instead as false, which is incorrect. Below is a part of the plan output that demonstrates this:

      request_setting.xxx.action:            "" => ""
      request_setting.xxx.bypass_busy_wait:  "false" => ""
      request_setting.xxx.default_host:      "foo.com" => "foo.com"
      request_setting.xxx.force_miss:        "false" => ""
      request_setting.xxx.force_ssl:         "false" => ""
      request_setting.xxx.geo_headers:       "false" => ""
      request_setting.xxx.hash_keys:         "" => ""
      request_setting.xxx.max_stale_age:     "0" => "60"
      request_setting.xxx.name:              "foo" => "foo"
      request_setting.xxx.request_condition: "conditional foo" => "conditional foo"
      request_setting.xxx.timer_support:     "false" => ""

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform import with those 5 unset / blank
  2. terraform plan with those 5

BigQuery: read Google Cloud env vars and don't require `project_id` to setup BigQuery logging

Terraform Version

v0.11.8

Affected Resource(s)

  • BigQuery logging

Description

The google terraform provider reads the project id with this order of precedence:

GOOGLE_PROJECT
GOOGLE_CLOUD_PROJECT
GCLOUD_PROJECT
CLOUDSDK_CORE_PROJECT

documented here

Would it be possible to make project_id (here if I'm reading this correctly) not a required parameter?

This is my suggestion:
If project_id is specified, use the value of the parameter, if not default to the precedence logic defined by the google terraform provider?

I don't have experience with the project but happy to contribute if you think this would be a good idea.

Fastly provider 0.4 - when applying VCL code that references resources like tables or snippets already included on the service - throws an error

Hi there,

Terraform Provider Version

0.4

Behavior

We have a Fastly Service, which is maintained through terraform, meaning properties and vcl are uploaded with terraform and the terraform fastly provider.

On this fastly service, through the API we have added, a dynamic snippet, which contains a table (dictionary)

Example

# Snippet search_redirects : 100
 # --- Fastly Synchronizer - START # --- Fastly Synchronizer - UPDATE DATE:2018-10-03T11:50:00.071
  table search_redirects { "santa+pod+raceway": "/santapod","elton john":}

On our terraformed Fastly configuration - we do include either on the Main.vcl or other vcl files which are added to the service - code that references..this table!. Since the snippet is versioned independently from the fastly service it is always available.

For example we added ...the snippet on version 40 of a service. Then we run our terraform fastly pipeline which increments the service to version 41 and includes code on the Main.vcl like this

  # Search redirects based on the fastly dictionaryt and not on TMOL proxies
  # /search&user_input=mel+c&q=Melanie+C
  if(req.url.path ~ "^/search"){
      declare local var.qParam STRING;
      declare local var.qParamLink STRING;
      set var.qParam = subfield(req.url.qs, "q", "&");
      set var.qParam = urldecode(var.qParam);
      set var.qParamLink = table.lookup(search_redirects, std.tolower(var.qParam),"NOT_FOUND");

      }
    }

So the uploaded VCL in this case is the Main.vcl references...and specifically the line

      set var.qParamLink = table.lookup(search_redirects, std.tolower(var.qParam),"NOT_FOUND");

Assumes that there is on the service level this table!

ALL THE ABOVE WERE WORKING fine with fastly provider 0.3 .

Now 17 hours after re-running the same pipeline .....on the above conditions with provider. 0.4 during the apply phase, when the above already established VCL is applied - Fastly reports an error
Like the followig


* fastly_service_v1.tmolauprod: [ERR] Invalid configuration for Fastly Service (xxxx): Undefined `table search_redirects`
at: (input Line 271 Pos 39)
    set var.qParamLink = table.lookup(search_redirects, std.tolower(var.qParam),"NOT_FOUND");

It seems when the VCL that references the table (from the snippet) it kind of ends up on a compile error - like the table is not there any more.

When you apply the same thing ...using provider 0.3 everything works.

provider "fastly" {
 version = "0.3"
}

Terraform apply fails with "Record not found / Cannot find 'service'"

Hi there,

I hope this counts as a bug report and not a general help question. I am trying to create a Fastly service with Terraform. When I run terraform apply, Terraform fails with an error that does not tell me what is wrong.

Terraform Version

Terraform v0.11.8

  • provider.fastly v0.3.0

Affected Resource(s)

  • fastly_service_v1

Terraform Configuration Files

provider "fastly" {
  api_key = "hunter2"
}
resource "fastly_service_v1" "app" {
  name = "app"

  domain {
    name    = "app.amitree-staging.com"
    comment = "demo"
  }
}

Debug Output

https://gist.github.com/sansb/47f860b46dd1250045d1d68bb590c70d

Expected Behavior

If the build fails, Terraform should tell me why

Actual Behavior

Terraform prints this:

* fastly_service_v1.app: 404 - Not Found:

    Title:  Record not found
    Detail: Cannot find 'service'

Steps to Reproduce

Run terraform apply

Unable to set backend ssl_ciphers

Terraform Version

$ tf --version
Terraform v0.11.7

  • provider.fastly v0.1.4

Affected Resource(s)

  • fastly_service_v1.backend

Terraform Configuration Files

provider "fastly" {
  api_key = "${ var.fastly_token }"
}

resource "fastly_service_v1" "test-cipher" {
  name        = "test-cipher"

  domain    { name = "${ var.domain }" }

  backend {
    name                = "test-cipher"
    address             = "${ var.backend_addr }"
    port                = 443
    use_ssl             = true
    ssl_cert_hostname   = "${ var.cert_hostname }"
    ssl_ca_cert         = "${ var.ca_cert }"
    min_tls_version     = "1.2"
    max_tls_version     = "1.2"
    ssl_ciphers         = "ECDHE-RSA-AES128-GCM-SHA256"
  }

  force_destroy = true
}

Debug Output

https://gist.github.com/jeff-lee/caddc2e6abb6a2f39a7b73adf5945194

Expected Behavior

The backend should be configured with the specified ssl ciphers

Actual Behavior

The backend was created with null ssl ciphers

Steps to Reproduce

  1. terraform apply

Feature Request: Comments on serviceIDs

Currently it's set to "Managed by Terraform".

......
"comment": "Managed by Terraform",
"customer_id": "asdf",
"updated_at": "2017-01-16T19:00:24Z",
"id": "qwerty"
.....

Would like to be able to set or configure the comment.

There is no way to associate health checks with backend origin servers

Terraform Version

Terraform v0.9.11

Affected Resource(s)

  • fastly_service_v1

Terraform Configuration Files

resource "fastly_service_v1" "test" {
  name = "test"

  domain {
    name = "test.example.com"
  }

  backend {
    address          = "1.1.1.1"
    name             = "east"
    port             = 80
  }

  backend {
    address          = "2.2.2.2"
    name             = "west"
    port             = 80
  }

  healthcheck {
    name              = "beacon"
    host              = "test.example.com"
    path              = "/beacon.gif"
    method            = "HEAD"
    expected_response = 200
  }

}

Expected Behavior

There should be a parameter to allow a health check to be associated with a specific backend.

Actual Behavior

There is no way to associate a defined health check with a backend. The backend definitions in VCL end up being generated with no .probe = { } block. Health check definitions are effectively ignored.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. Define a fastly_service_v1 resource similar to the example above, and run terraform apply.

Question about submitting documentation fixes

While working with this provider, I've noticed a number of documentation issues. I'd like to help contribute by submitting fixes for docs, but I wanted to ask if this project is open to this, and if so, what is the best way to go about doing that? Is it better to submit one large PR, or break changes into multiple PRs that combine similar changes? I ask because PR #19 was quickly tagged documentation, but has been open for several weeks now without any feedback.

Some of the issues I've found:

  • primary resource name in sidebar is incorrect (PR #19)
  • some incorrectly documented parameters (PR #19 and possibly others)
  • inconsistent parameter ordering
  • inconsistent formatting compared to official provider documentation (AWS)
  • missing import documentation

Unclear output of plan/apply during custom VCL

Terraform Version

Terraform 0.11.7
Fastly Provider 0.1.4

Affected Resource(s)

fastly_service_v1

Terraform Configuration Files

{
  "resource": {
    "fastly_service_v1": {
      "fastly-cdn": {
        "domain": [
          {
            "name": "vcltest--cdn-gateway.elifesciences.org"
          }
        ],
        "name": "api-gateway--vcltest",
        "vcl": [
          {
            "content": "${file(\"gzip-by-regex.vcl\")}",
            "name": "gzip-by-regex"
          },
          {
            "content": "${file(\"main.vcl\")}",
            "main": true,
            "name": "main"
          }
        ],
        "force_destroy": true,
        "backend": {
          "name": "api-gateway--vcltest",
          "ssl_check_cert": true,
          "ssl_cert_hostname": "vcltest--gateway.elifesciences.org",
          "address": "vcltest--gateway.elifesciences.org",
          "use_ssl": true,
          "port": 443
        }
      }
    }
  }
}

Debug Output

https://gist.github.com/giorgiosironi/1886c616f69287cfc6a45fdf670240f3

Expected Behavior

A difference of the VCL files content should be shown? Not sure.

Actual Behavior

Terraform will perform the following actions:                                                                                     

  ~ fastly_service_v1.fastly-cdn
2018/05/11 14:53:32 [DEBUG] command: asking for input: "Do you want to perform these actions?"
      vcl.146061381.content:  "\n        if ((beresp.status == 200 || beresp.status == 404) && (beresp.http.content-type ~ \"(\\+json)\\s*(
$|;)\" || req.url ~ \"\\.(css|js|html|eot|ico|otf|ttf|json|svg)($|\\?)\" ) ) {\n          # always set vary to make sure uncompressed versi
ons dont always win\n          if (!beresp.http.Vary ~ \"Accept-Encoding\") {\n            if (beresp.http.Vary) {\n              set beres
p.http.Vary = beresp.http.Vary \", Accept-Encoding\";\n            } else {\n              set beresp.http.Vary = \"Accept-Encoding\";\n   
         }\n          }\n          if (req.http.Accept-Encoding == \"gzip\") {\n            set beresp.gzip = true;\n          }\n        }
\n        " => ""
      vcl.146061381.main:     "false" => "false"
      vcl.146061381.name:     "gzip-by-regex" => ""
      vcl.35407642.content:   "\n    sub vcl_recv {\n      #FASTLY recv\n\n      if (req.request != \"HEAD\" && req.request != \"GET\" && r
eq.request != \"FASTLYPURGE\") {\n        return(pass);\n      }\n\n      return(lookup);\n    }\n\n    sub vcl_fetch {\n      include \"gz
ip-by-regex\"\n\n      #FASTLY fetch\n\n      if ((beresp.status == 500 || beresp.status == 503) && req.restarts < 1 && (req.request == \"G
ET\" || req.request == \"HEAD\")) {\n        restart;\n      }\n\n      if (req.restarts > 0) {\n        set beresp.http.Fastly-Restarts = 
req.restarts;\n      }\n\n      if (beresp.http.Set-Cookie) {\n        set req.http.Fastly-Cachetype = \"SETCOOKIE\";\n        return(pass)
;\n      }\n\n      if (beresp.http.Cache-Control ~ \"private\") {\n        set req.http.Fastly-Cachetype = \"PRIVATE\";\n        return(pa
ss);\n      }\n\n      if (beresp.status == 500 || beresp.status == 503) {\n        set req.http.Fastly-Cachetype = \"ERROR\";\n        set
 beresp.ttl = 1s;\n        set beresp.grace = 5s;\n        return(deliver);\n      }\n\n      if (beresp.http.Expires || beresp.http.Surrog
ate-Control ~ \"max-age\" || beresp.http.Cache-Control ~ \"(s-maxage|max-age)\") {\n        # keep the ttl here\n      } else {\n        # 
apply the default ttl\n        set beresp.ttl = 3600s;\n      }\n\n      return(deliver);\n    }\n\n    sub vcl_hit {\n      #FASTLY hit\n\
n      if (!obj.cacheable) {\n        return(pass);\n      }\n      return(deliver);\n    }\n\n    sub vcl_miss {\n      #FASTLY miss\n    
  return(fetch);\n    }\n\n    sub vcl_deliver {\n      #FASTLY deliver\n      return(deliver);\n    }\n\n    sub vcl_error {\n      #FASTL
Y error\n    }\n\n    sub vcl_pass {\n      #FASTLY pass\n    }\n\n    sub vcl_log {\n      #FASTLY log\n    }" => ""
      vcl.35407642.main:      "true" => "false"
      vcl.35407642.name:      "main" => ""
      vcl.3971786474.content: "" => "053fc68844dddf1304514127ccac13fb253edc88"
      vcl.3971786474.main:    "" => "true"
      vcl.3971786474.name:    "" => "main"
      vcl.751199481.content:  "" => "82a663ca3ed1f63352fb1f3b348bd43fc9c34b7e"
      vcl.751199481.main:     "" => "false"
      vcl.751199481.name:     "" => "gzip-by-regex"

It seems the VCL snippets (one main and one not) are being removed and added again, which is fine. But I would expect to see what am I adding, this hash appears instead. In fact I see the full strings in the removed VCL snippets.

Not sure if anything can be done in a provider about the \n as it may be how Terraform shows multiline strings.

Steps to Reproduce

  1. terraform apply

Important Factoids

Requires a Fastly account with custom VCL enabled.
I'm available to do a patch if someone can point me in the right direction.

s3logging acceptance tests fail in TestAccFastlyServiceV1_s3logging_domain_default

Acceptance tests for the s3logging sub resource fail due to missing MessageType parameter in the TestAccFastlyServiceV1_s3logging_domain_default definition.

$ make && TESTARGS=-run=TestAccFastlyServiceV1_s3logging_domain_default make testacc

==> Checking that code complies with gofmt requirements...
go install
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test $(go list ./... |grep -v 'vendor') -v -run=TestAccFastlyServiceV1_s3logging_domain_default -timeout 120m
?       github.com/terraform-providers/terraform-provider-fastly        [no test files]
=== RUN   TestAccFastlyServiceV1_s3logging_domain_default
--- FAIL: TestAccFastlyServiceV1_s3logging_domain_default (8.82s)
        testing.go:428: Step 0 error: Check failed: Check 2/5 error: Bad match S3 logging match, expected (&fastly.S3{ServiceID:"5QwmzXr4nVSyypgPYWCU1G", Version:1, Name:"somebucketlog", BucketName:"fastlytestlogging", Domain:"s3.amazonaws.com", AccessKey:"somekey", SecretKey:"somesecret", Path:"", Period:0xe10, GzipLevel:0x0, Format:"%h %l %u %t %r %>s", FormatVersion:0x1, ResponseCondition:"response_condition_test", MessageType:"", TimestampFormat:"%Y-%m-%dT%H:%M:%S.000", Redundancy:"", CreatedAt:(*time.Time)(nil), UpdatedAt:(*time.Time)(nil), DeletedAt:(*time.Time)(nil)}), got (&fastly.S3{ServiceID:"5QwmzXr4nVSyypgPYWCU1G", Version:1, Name:"somebucketlog", BucketName:"fastlytestlogging", Domain:"s3.amazonaws.com", AccessKey:"somekey", SecretKey:"somesecret", Path:"", Period:0xe10, GzipLevel:0x0, Format:"%h %l %u %t %r %>s", FormatVersion:0x1, ResponseCondition:"response_condition_test", MessageType:"classic", TimestampFormat:"%Y-%m-%dT%H:%M:%S.000", Redundancy:"", CreatedAt:(*time.Time)(nil), UpdatedAt:(*time.Time)(nil), DeletedAt:(*time.Time)(nil)})
FAIL
FAIL    github.com/terraform-providers/terraform-provider-fastly/fastly 8.841s
make: *** [testacc] Error 1

The following change fixes that specific error.

diff --git a/fastly/resource_fastly_service_v1_s3logging_test.go b/fastly/resource_fastly_service_v1_s3logging_test.go
index 1956f29..a6d4c84 100644
--- a/fastly/resource_fastly_service_v1_s3logging_test.go
+++ b/fastly/resource_fastly_service_v1_s3logging_test.go
@@ -113,6 +113,7 @@ func TestAccFastlyServiceV1_s3logging_domain_default(t *testing.T) {
                Format:            "%h %l %u %t %r %>s",
                FormatVersion:     1,
                TimestampFormat:   "%Y-%m-%dT%H:%M:%S.000",
+               MessageType:       "classic",
                ResponseCondition: "response_condition_test",
        }

However, even if this error is fixed, testing still fails due to hardcoded resource ID in the same test at line 134: https://github.com/terraform-providers/terraform-provider-fastly/blob/master/fastly/resource_fastly_service_v1_s3logging_test.go#L134. The resource key s3logging.910866243.domain is not deterministic and would be different for every machine that runs these acceptance tests.

But, the test is already checking that the domain attribute has s3.amazonaws.com in it, isn't it? It's not set in the config function below on line 271, so it must come from the resource defaults.

$ make && TESTARGS=-run=TestAccFastlyServiceV1_s3logging_domain_default make testacc

==> Checking that code complies with gofmt requirements...
go install
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test $(go list ./... |grep -v 'vendor') -v -run=TestAccFastlyServiceV1_s3logging_domain_default -timeout 120m
?       github.com/terraform-providers/terraform-provider-fastly        [no test files]
=== RUN   TestAccFastlyServiceV1_s3logging_domain_default
--- FAIL: TestAccFastlyServiceV1_s3logging_domain_default (9.44s)
        testing.go:428: Step 0 error: Check failed: Check 5/5 error: fastly_service_v1.foo: Attribute 's3logging.910866243.domain' not found
FAIL
FAIL    github.com/terraform-providers/terraform-provider-fastly/fastly 9.456s
make: *** [testacc] Error 1

State for Conditions doesn't seem to be saved or accounted for

terraform versions: 0.10.7 & 0.11.2
fastly: 0.1.4

After successfully running terraform apply, you would expect that running terraform plan right away have no changes. But it seems that conditions always needs to be re-modified. Doing a diff in fastly, shows not difference but a new version is still incremented.

see below for the apply followed by plan
(FQDN replaced with generic)

After successfully running terraform apply, you would expect that running terraform plan right away have no changes. But it seems that conditions always needs to be re-modified. Doing a diff in fastly, shows not difference but a new version is still incremented.

see below for the apply followed by plan
(FQDN replaced with generic)

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.

Enter a value: yes

fastly_service_v1.dev-example: Modifying... (ID: someID)
condition.1325525563.name: "" => "http-condition_www.example.com"
condition.1325525563.priority: "" => "103"
condition.1325525563.statement: "" => "!req.http.Fastly-SSL && req.http.Host ~ "^www.example.com""
condition.1325525563.type: "" => "request"
condition.1491153257.name: "" => "response_condition apex redirect to www"
condition.1491153257.priority: "" => "10"
condition.1491153257.statement: "" => "req.http.host == "example.com""
condition.1491153257.type: "" => "request"
condition.1556405024.name: "http-condition_testz.example.com" => ""
condition.1556405024.priority: "100" => "0"
condition.1556405024.statement: "!req.http.Fastly-SSL && req.http.Host ~ "^testz.example.com"" => ""
condition.1556405024.type: "REQUEST" => ""
condition.1722969688.name: "hho-condition_testz.example.com" => ""
condition.1722969688.priority: "103" => "0"
condition.1722969688.statement: "req.http.Host ~ "testz.example.com"" => ""
condition.1722969688.type: "REQUEST" => ""
condition.1918102658.name: "" => "response_condition redirect to testz"
condition.1918102658.priority: "" => "10"
condition.1918102658.statement: "" => "req.http.host == "www.example.com""
condition.1918102658.type: "" => "request"
condition.2400079878.name: "response_condition redirect to testz" => ""
condition.2400079878.priority: "10" => "0"
condition.2400079878.statement: "req.http.host == "www.example.com"" => ""
condition.2400079878.type: "REQUEST" => ""
condition.2520921681.name: "response_condition_redirect www.example.com" => ""
condition.2520921681.priority: "10" => "0"
condition.2520921681.statement: "req.http.host == "www.example.com" && resp.status == 301" => ""
condition.2520921681.type: "RESPONSE" => ""
condition.2616185564.name: "" => "hho-condition_testz.example.com"
condition.2616185564.priority: "" => "103"
condition.2616185564.statement: "" => "req.http.Host ~ "testz.example.com""
condition.2616185564.type: "" => "request"
condition.2711185316.name: "" => "http-condition_testz.example.com"
condition.2711185316.priority: "" => "100"
condition.2711185316.statement: "" => "!req.http.Fastly-SSL && req.http.Host ~ "^testz.example.com""
condition.2711185316.type: "" => "request"
condition.2780597741.name: "response_condition apex redirect to www" => ""
condition.2780597741.priority: "10" => "0"
condition.2780597741.statement: "req.http.host == "example.com"" => ""
condition.2780597741.type: "REQUEST" => ""
condition.2859898404.name: "response_condition_redirect example.com" => ""
condition.2859898404.priority: "10" => "0"
condition.2859898404.statement: "req.http.host == "example.com" && resp.status == 301" => ""
condition.2859898404.type: "RESPONSE" => ""
condition.2992395967.name: "http-condition_www.example.com" => ""
condition.2992395967.priority: "103" => "0"
condition.2992395967.statement: "!req.http.Fastly-SSL && req.http.Host ~ "^www.example.com"" => ""
condition.2992395967.type: "REQUEST" => ""
condition.3487387107.name: "hho-condition_www.example.com" => ""
condition.3487387107.priority: "106" => "0"
condition.3487387107.statement: "req.http.Host ~ "www.example.com"" => ""
condition.3487387107.type: "REQUEST" => ""
condition.3587876867.name: "" => "response_condition_redirect example.com"
condition.3587876867.priority: "" => "10"
condition.3587876867.statement: "" => "req.http.host == "example.com" && resp.status == 301"
condition.3587876867.type: "" => "response"
condition.3709459421.name: "" => "https-condition_testz.example.com"
condition.3709459421.priority: "" => "101"
condition.3709459421.statement: "" => "req.http.Fastly-SSL && req.http.Host ~ "^testz.example.com""
condition.3709459421.type: "" => "request"
condition.388083011.name: "" => "https-condition_www.example.com"
condition.388083011.priority: "" => "104"
condition.388083011.statement: "" => "req.http.Fastly-SSL && req.http.Host ~ "^www.example.com""
condition.388083011.type: "" => "request"
condition.3924691062.name: "" => "response_condition_redirect www.example.com"
condition.3924691062.priority: "" => "10"
condition.3924691062.statement: "" => "req.http.host == "www.example.com" && resp.status == 301"
condition.3924691062.type: "" => "response"
condition.3933999559.name: "https-condition_www.example.com" => ""
condition.3933999559.priority: "104" => "0"
condition.3933999559.statement: "req.http.Fastly-SSL && req.http.Host ~ "^www.example.com"" => ""
condition.3933999559.type: "REQUEST" => ""
condition.541353817.name: "https-condition_testz.example.com" => ""
condition.541353817.priority: "101" => "0"
condition.541353817.statement: "req.http.Fastly-SSL && req.http.Host ~ "^testz.example.com"" => ""
condition.541353817.type: "REQUEST" => ""
condition.847311207.name: "" => "hho-condition_www.example.com"
condition.847311207.priority: "" => "106"
condition.847311207.statement: "" => "req.http.Host ~ "www.example.com""
condition.847311207.type: "" => "request"
fastly_service_v1.dev-example: Still modifying... (ID: someID, 10s elapsed)
fastly_service_v1.dev-example: Modifications complete after 16s (ID: someID)

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Plan
terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

fastly_service_v1.dev-example: Refreshing state... (ID: someID)
dyn_record.testz-example-com: Refreshing state... (ID: 328664909)
dyn_record.example-com_3: Refreshing state... (ID: 328879903)
dyn_record.example-com_1: Refreshing state... (ID: 328879912)
dyn_record.example-com_2: Refreshing state... (ID: 328879911)
dyn_record.testz-example-com-cdn-example-net: Refreshing state... (ID: 328664920)
dyn_record.www-example-com: Refreshing state... (ID: 328664913)
dyn_record.www-example-com-cdn-example-net: Refreshing state... (ID: 328664919)


An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
~ update in-place

Terraform will perform the following actions:

~ fastly_service_v1.dev-example
condition.1325525563.name: "" => "http-condition_www.example.com"
condition.1325525563.priority: "" => "103"
condition.1325525563.statement: "" => "!req.http.Fastly-SSL && req.http.Host ~ "^www.example.com""
condition.1325525563.type: "" => "request"
condition.1491153257.name: "" => "response_condition apex redirect to www"
condition.1491153257.priority: "" => "10"
condition.1491153257.statement: "" => "req.http.host == "example.com""
condition.1491153257.type: "" => "request"
condition.1556405024.name: "http-condition_testz.example.com" => ""
condition.1556405024.priority: "100" => "0"
condition.1556405024.statement: "!req.http.Fastly-SSL && req.http.Host ~ "^testz.example.com"" => ""
condition.1556405024.type: "REQUEST" => ""
condition.1722969688.name: "hho-condition_testz.example.com" => ""
condition.1722969688.priority: "103" => "0"
condition.1722969688.statement: "req.http.Host ~ "testz.example.com"" => ""
condition.1722969688.type: "REQUEST" => ""
condition.1918102658.name: "" => "response_condition redirect to testz"
condition.1918102658.priority: "" => "10"
condition.1918102658.statement: "" => "req.http.host == "www.example.com""
condition.1918102658.type: "" => "request"
condition.2400079878.name: "response_condition redirect to testz" => ""
condition.2400079878.priority: "10" => "0"
condition.2400079878.statement: "req.http.host == "www.example.com"" => ""
condition.2400079878.type: "REQUEST" => ""
condition.2520921681.name: "response_condition_redirect www.example.com" => ""
condition.2520921681.priority: "10" => "0"
condition.2520921681.statement: "req.http.host == "www.example.com" && resp.status == 301" => ""
condition.2520921681.type: "RESPONSE" => ""
condition.2616185564.name: "" => "hho-condition_testz.example.com"
condition.2616185564.priority: "" => "103"
condition.2616185564.statement: "" => "req.http.Host ~ "testz.example.com""
condition.2616185564.type: "" => "request"
condition.2711185316.name: "" => "http-condition_testz.example.com"
condition.2711185316.priority: "" => "100"
condition.2711185316.statement: "" => "!req.http.Fastly-SSL && req.http.Host ~ "^testz.example.com""
condition.2711185316.type: "" => "request"
condition.2780597741.name: "response_condition apex redirect to www" => ""
condition.2780597741.priority: "10" => "0"
condition.2780597741.statement: "req.http.host == "example.com"" => ""
condition.2780597741.type: "REQUEST" => ""
condition.2859898404.name: "response_condition_redirect example.com" => ""
condition.2859898404.priority: "10" => "0"
condition.2859898404.statement: "req.http.host == "example.com" && resp.status == 301" => ""
condition.2859898404.type: "RESPONSE" => ""
condition.2992395967.name: "http-condition_www.example.com" => ""
condition.2992395967.priority: "103" => "0"
condition.2992395967.statement: "!req.http.Fastly-SSL && req.http.Host ~ "^www.example.com"" => ""
condition.2992395967.type: "REQUEST" => ""
condition.3487387107.name: "hho-condition_www.example.com" => ""
condition.3487387107.priority: "106" => "0"
condition.3487387107.statement: "req.http.Host ~ "www.example.com"" => ""
condition.3487387107.type: "REQUEST" => ""
condition.3587876867.name: "" => "response_condition_redirect example.com"
condition.3587876867.priority: "" => "10"
condition.3587876867.statement: "" => "req.http.host == "example.com" && resp.status == 301"
condition.3587876867.type: "" => "response"
condition.3709459421.name: "" => "https-condition_testz.example.com"
condition.3709459421.priority: "" => "101"
condition.3709459421.statement: "" => "req.http.Fastly-SSL && req.http.Host ~ "^testz.example.com""
condition.3709459421.type: "" => "request"
condition.388083011.name: "" => "https-condition_www.example.com"
condition.388083011.priority: "" => "104"
condition.388083011.statement: "" => "req.http.Fastly-SSL && req.http.Host ~ "^www.example.com""
condition.388083011.type: "" => "request"
condition.3924691062.name: "" => "response_condition_redirect www.example.com"
condition.3924691062.priority: "" => "10"
condition.3924691062.statement: "" => "req.http.host == "www.example.com" && resp.status == 301"
condition.3924691062.type: "" => "response"
condition.3933999559.name: "https-condition_www.example.com" => ""
condition.3933999559.priority: "104" => "0"
condition.3933999559.statement: "req.http.Fastly-SSL && req.http.Host ~ "^www.example.com"" => ""
condition.3933999559.type: "REQUEST" => ""
condition.541353817.name: "https-condition_testz.example.com" => ""
condition.541353817.priority: "101" => "0"
condition.541353817.statement: "req.http.Fastly-SSL && req.http.Host ~ "^testz.example.com"" => ""
condition.541353817.type: "REQUEST" => ""
condition.847311207.name: "" => "hho-condition_www.example.com"
condition.847311207.priority: "" => "106"
condition.847311207.statement: "" => "req.http.Host ~ "www.example.com""
condition.847311207.type: "" => "request"

Plan: 0 to add, 1 to change, 0 to destroy.


Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

Feature Request: Remove need for API key when using fastly_ip_ranges data source.

Terraform Version

v0.11.7

Affected Provider

  • Fastly

Expected Behavior

Providing a Fastly API key should be optional when calling data "fastly_ip_ranges" "fastly" {}.

Actual Behavior

Terraform will error out if a key is not provided when calling just the above.

Error: Error refreshing state: 1 error(s) occurred:
* provider.fastly: [Err] No API key for Fastly

Steps to Reproduce

  1. Comment out api_key in the manifest
provider "fastly" {
#  api_key = "96516f75a33f9f255b780e9b8e9eb99b"
}
data "fastly_ip_ranges" "fastly" {}
  1. terraform plan

Important Factoids

https://api.fastly.com/public-ip-list is public endpoint. If this is the only function used in the Fastly provider set, there is no need for an API key. This was the case for me when using fastly_ip_ranges to keep our AWS security groups up to date. I didn't want to keep an API key in SCM, so I created a read-only token, but this is still less than ideal.

The conditional in config.go puts a hard stop on this:

	if c.ApiKey == "" {
		return nil, fmt.Errorf("[Err] No API key for Fastly")

s3logging changes on each apply even if HCL did not change

Terraform Version

0.9.9

Affected Resource(s)

  • fastly_service_v1

Terraform Configuration Files

...
  # NOTE: This config defines the S3 destination, but no
  # logging happens here (it's done in custom VCL)
  s3logging {
    name               = "S3 Logs"
    bucket_name        = "my_bucket"
    s3_access_key      = "foo"
    s3_secret_key      = "bar"
    path               = "logs/fastly/"
    period             = "900"
    gzip_level         = "1"
    response_condition = "Priority 20 Always False"
    format             = "%h %l %u %t %r %>s req.http.x-log-host resp.http.X-Cache req.http.x-forwarded-for req.http.range"
  }
...

Debug Output

~ fastly_service_v1.pl
    s3logging.1412920004.bucket_name:        "" => "my_bucket"
    s3logging.1412920004.domain:             "" => ""
    s3logging.1412920004.format:             "" => "%h %l %u %t %r %>s req.http.x-log-host resp.http.X-Cache req.http.x-forwarded-for req.http.range"
    s3logging.1412920004.format_version:     "" => "1"
    s3logging.1412920004.gzip_level:         "" => "1"
    s3logging.1412920004.name:               "" => "S3 Logs"
    s3logging.1412920004.path:               "" => "logs/fastly/"
    s3logging.1412920004.period:             "" => "900"
    s3logging.1412920004.response_condition: "" => "Priority 20 Always False"
    s3logging.1412920004.s3_access_key:      "<sensitive>" => "<sensitive>" (attribute changed)
    s3logging.1412920004.s3_secret_key:      "<sensitive>" => "<sensitive>" (attribute changed)
    s3logging.1412920004.timestamp_format:   "" => "%Y-%m-%dT%H:%M:%S.000"
    s3logging.3742254017.bucket_name:        "my_bucket" => ""
    s3logging.3742254017.domain:             "s3.amazonaws.com" => ""
    s3logging.3742254017.format:             "%h %l %u %t %r %>s req.http.x-log-host resp.http.X-Cache req.http.x-forwarded-for req.http.range" => ""
    s3logging.3742254017.format_version:     "1" => "0"
    s3logging.3742254017.gzip_level:         "1" => "0"
    s3logging.3742254017.name:               "S3 Logs" => ""
    s3logging.3742254017.path:               "logs/fastly/" => ""
    s3logging.3742254017.period:             "900" => "0"
    s3logging.3742254017.response_condition: "Priority 20 Always False" => ""
    s3logging.3742254017.s3_access_key:      "" => ""
    s3logging.3742254017.s3_secret_key:      "" => ""
    s3logging.3742254017.timestamp_format:   "%Y-%m-%dT%H:%M:%S.000" => ""

Panic Output

n/a

Expected Behavior

The resource should not be changed

Actual Behavior

Terraform changes the resources, even though the contents of the old and new resources are the same.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform apply

Important Factoids

n/a

References

cc @catsby, we just talked about this during the break in your presentation at Altitude

Healthcheck parameter set to default value in state

When setting the initial field of a healthcheck to 0, Fastly does not update its configuration and TF sets its default value for that field in its remote state. A subsequent plan describes the healthcheck as having changed because of this and attempts to set it back to the value in the TF config.

I'm not sure if 0 is an acceptable value to Fastly for the initial field of a healthcheck (hence it not updating its config), but I am confused about why the provider has stored the default value in its state.

Terraform Version

Terraform v0.11.7

  • provider.external v1.0.0
  • provider.fastly v0.2.0
  • provider.google v1.16.2

Affected Resource(s)

  • fastly.fastly_service_v1

Expected Behavior

The initial field of the healthcheck was expected to be set to 0 when applying the configuration.

Actual Behavior

When applying, the initial field of the healthcheck was left at its previous value by Fastly (1) and the TF remote state records it as being 2, which is the default value for this field in the provider. TF reports no problems occurred.

Output of terraform apply

  healthcheck.3168930295.check_interval:    "5000" => "0"
  healthcheck.3168930295.expected_response: "200" => "0"
  healthcheck.3168930295.host:              "xxx" => ""
  healthcheck.3168930295.http_version:      "1.1" => ""
  healthcheck.3168930295.initial:           "1" => "0"
  healthcheck.3168930295.method:            "HEAD" => ""
  healthcheck.3168930295.name:              "xxx" => ""
  healthcheck.3168930295.path:              "/xxx" => ""
  healthcheck.3168930295.threshold:         "2" => "0"
  healthcheck.3168930295.timeout:           "5000" => "0"
  healthcheck.3168930295.window:            "5" => "0"
  healthcheck.3592920224.check_interval:    "" => "5000"
  healthcheck.3592920224.expected_response: "" => "200"
  healthcheck.3592920224.host:              "" => "xxx"
  healthcheck.3592920224.http_version:      "" => "1.1"
  healthcheck.3592920224.initial:           "" => "0"
  healthcheck.3592920224.method:            "" => "HEAD"
  healthcheck.3592920224.name:              "" => "xxx"
  healthcheck.3592920224.path:              "" => "/xxx"
  healthcheck.3592920224.threshold:         "" => "2"
  healthcheck.3592920224.timeout:           "" => "5000"
  healthcheck.3592920224.window:            "" => "5"

Output of subsequent terraform plan

      healthcheck.3592920224.check_interval:    "" => "5000"
      healthcheck.3592920224.expected_response: "" => "200"
      healthcheck.3592920224.host:              "" => "xxx"
      healthcheck.3592920224.http_version:      "" => "1.1"
      healthcheck.3592920224.initial:           "" => "0"
      healthcheck.3592920224.method:            "" => "HEAD"
      healthcheck.3592920224.name:              "" => "xxx"
      healthcheck.3592920224.path:              "" => "/xxx"
      healthcheck.3592920224.threshold:         "" => "2"
      healthcheck.3592920224.timeout:           "" => "5000"
      healthcheck.3592920224.window:            "" => "5"
      healthcheck.61650446.check_interval:      "5000" => "0"
      healthcheck.61650446.expected_response:   "200" => "0"
      healthcheck.61650446.host:                "xxx" => ""
      healthcheck.61650446.http_version:        "1.1" => ""
      healthcheck.61650446.initial:             "2" => "0"
      healthcheck.61650446.method:              "HEAD" => ""
      healthcheck.61650446.name:                "xxx" => ""
      healthcheck.61650446.path:                "/xxx" => ""
      healthcheck.61650446.threshold:           "2" => "0"
      healthcheck.61650446.timeout:             "5000" => "0"
      healthcheck.61650446.window:              "5" => "0"

Build logs expose secrets

We're looking to open source a few Terraformed Fastly projects.

One of the tricky parts it in secrets being output in the build logs, in our case they exist in VCL resources, the values imported in using variables and templates.

Is there a way we can prevent this? Having secrets in the build log, open or closed source, I'm not a big fan of.

cc @phamann

syslog logging

There's no way to configure syslog logging for Fastly with current fastly provider.

Can't override default_host = "" of Terraform

Hello,

Terraform Version

Terraform v0.11.7

  • provider.fastly v0.1.4

Affected Resource(s)

fastly_service_v1

Terraform Configuration Files

resource "fastly_service_v1" "myservice" {
  name = "xxxxxxxxxxx.global.ssl.fastly.net"

  domain {
    name = "xxxxxxxxxxx.global.ssl.fastly.net"
  }

  backend {
    address = "10.0.0.1"
    name    = "Temp"
    port    = 80
  }

  default_ttl   = 10
  force_destroy = true
  default_host = ""

  vcl {
    name    = "main"
    main    = "true"
    content = "${file("main.vcl")}"
  }
}

Expected Behavior

Override Host header of Fastly should be deleted

Actual Behavior

No changes. Infrastructure is up-to-date. by terraform apply

Steps to Reproduce

  1. set default_host = "" in override.tf
  2. terraform apply

Important Factoids

When I set default_host = false, it will set 0 for Override Host of Fastly UI, but it deletes in actual vcl line of set req.http.host = xxxx

Cannot delete a fastly service via destroy

Terraform Version

Terraform v0.10.7

Affected Resource(s)

  • fastly_service_v1

Terraform Configuration Files

Any valid config file.

Expected Behavior

The Fastly service should be deleted.

Actual Behavior

Error out and leaves the service running:

$ terraform destroy
fastly_service_v1.CDN-test-DEV: Refreshing state... (ID: 51tOMbWo0ZsEaiqjleB5eC)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  - fastly_service_v1.CDN-test-DEV


Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

fastly_service_v1.CDN-test-DEV: Destroying... (ID: 51tOMbWo0ZsEaiqjleB5eC)
Error applying plan:

1 error(s) occurred:

* fastly_service_v1.CDN-test-DEV (destroy): 1 error(s) occurred:

* fastly_service_v1.CDN-test-DEV: 400 - Bad Request
Message: Bad request
Detail: Cannot delete service with active version

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:
Try to delete a service, e.g.
terraform destroy or
terraform destroy -target=fastly_service_v1.CDN-test-DEV

Support for Syslog logging

Hi,

At the moment fastly provider does support S3 logging endpoint but it would be nice to have possibility to template as well syslog logging endpoints.

Regards,
Constantin

Slashes in Condition Names cause 404s when modifying

terraform versions: 0.10.7 & 0.11.7
fastly provider: 0.1.4

when you create a response condition name with slashes:

response_object {
name = "301 response for www.example.com/some/path"
status = 301
request_condition = "response_condition_redirect for www.example.com/some/path"
}

and then try to make a change to it from 301 to 302

response_object {
name = "301 response for www.example.com/some/path"
status = 302
request_condition = "response_condition_redirect for www.example.com/some/path"
}

You get a terraform error:

fastly_service_v1.some-website: 1 error(s) occurred:
fastly_service_v1.some-website: 404 - Not Found

Even though the service ID is valid and works.

Likely related to fastly/go-fastly#66

So it looks like you can create the conditions with slashes but you can not modify it afterwards.

provider/fastly Allow passing a dynamic list of domains to the fastly service

This issue was originally opened by @msuterski as hashicorp/terraform#11322. It was migrated here as part of the provider split. The original body of the issue is below.


Fastly allows attaching multiple domains to their services.

Current behavior:
To attach multiple domains to the Fastly's service they need to be listed explicitly one by one

resource "fastly_service_v1" "myservice" {
  name = "myservice.prd"

  domain {
    name = "myservice.example.com"
    comment = ""
  }

  domain {
    name = "myservice1.example.com"
    comment = ""
  }
...
}

This is very inconvenient (actually a deal breaker for us) when we'd like to reuse the same service configuration across different environments. I.e. in dev we might have 1 or 2 domains, but in prd we might have 20.

Expected behavior:

Pass a list of domains through a variable and the resources will be generated appropriately. Something like:

resource "fastly_service_v1" "myservice" {
  name = "myservice.prd"

  domain {
    count = "${length(var.domains)}"
    name = "${element(var.domains, count.index)}"
    comment = ""
  }
...
}

This is similar to hashicorp/terraform#4726 but I'm not sure if it's going to be solved by linked to it https://github.com/hashicorp/terraform/issues/2275. The domains in Fastly cannot be created outside of the service create/update "transaction".

Similar limitation applies to backend resource, but this one can be workaround'ed with including backends definitions in custom VCL. But ideally, same fix could be made to the backend.

Acceptance tests fail because of hardcoded domain name

The acceptance tests in the latest master (2ea108d) are failing due to domain collision in Fastly. It happens probably when the test suite is run by multiple people at the same time.

--- FAIL: TestAccFastlyServiceV1_VCL_basic (6.69s)
	testing.go:428: Step 0 error: Error applying: 1 error(s) occurred:

		* fastly_service_v1.foo: 1 error(s) occurred:

		* fastly_service_v1.foo: 400 - Bad Request
		Message: Bad request
		Detail: Domain 'notadomain.com' is already taken by another customer
=== RUN   TestValidateLoggingFormatVersion
--- PASS: TestValidateLoggingFormatVersion (0.00s)
=== RUN   TestValidateLoggingMessageType
--- PASS: TestValidateLoggingMessageType (0.00s)
FAIL
FAIL	github.com/terraform-providers/terraform-provider-fastly/fastly	247.298s
make: *** [testacc] Error 1

Terraform Version

Tests were run on the Fastly provider repo. Not sure which version of terraform the tests pulled in.

Expected Behavior

Tests should pass

Actual Behavior

TestAccFastlyServiceV1_VCL_basic test case failed

Steps to Reproduce

  1. make testacc

Support Fastly S3 logging message_type

This issue was originally opened by @DanielRussell as hashicorp/terraform#14690. It was migrated here as part of the provider split. The original body of the issue is below.


Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

0.9.2 (reviewed source for master, feature is not present)

Affected Resource(s)

  • fastly_service_v1

Terraform Configuration Files

 "fastly_service_v1" "pl" {
  s3logging {
    name               = "S3 Logs"
    bucket_name        = "mybucket"
    message_format     = "blank"
  }

Debug Output

* fastly_service_v1.pl: s3logging.0: invalid or unknown key: message_format

Expected Behavior

Terraform should configure the S3 log resource with any of the supported message_format types.

Actual Behavior

* fastly_service_v1.pl: s3logging.0: invalid or unknown key: message_format

Steps to Reproduce

  1. Create terraform configuration file
  2. terraform apply

References

This feature is supported in the sumologic config item; at a glance it looks like a copy/paste in a few places will suffice.

As Fastly allows message_type on all log configurations, ideally this feature would be provided to all. However, for my specific use case I'm only using S3.

Import of services and write out .tf, but many things want to "change"

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

0.11.7

Affected Resource(s)

fast;y_service_v1

Expected Behavior

Import service > write out resource and associated blocks > run plan, see no changes

Actual Behavior

Import service > write out resource and associated bloack > run plan, see multiple blocks want to make "changes" These changes are sometimes a "1" => "1" change, or are sometimes a "1" => "" then "" => "1" destroy and rebuild sort of change.

for the 1 => 1 change, it is easy to see that there are actually no changes, however in the others its tough to match up, making me hesitant to run apply, since there is currently no way to do a VCL diff before activation.

below is my plan output:

~ fastly_service_v1.s3external
      condition.125405225.name:                     "Fastly Example" => "Fastly Example"
      condition.125405225.priority:                 "10" => "10"
      condition.125405225.statement:                "req.http.Host == \"fastly.example.com\"" => "req.http.Host == \"fastly.example.com\""
      condition.125405225.type:                     "REQUEST" => "REQUEST"
      condition.1264234030.name:                    "Generic 404" => "Generic 404"
      condition.1264234030.priority:                "10" => "10"
      condition.1264234030.statement:               "beresp.status == 404" => "beresp.status == 404"
      condition.1264234030.type:                    "CACHE" => "CACHE"
      condition.142207472.name:                     "" => "XYZ"
      condition.142207472.priority:                 "" => "10"
      condition.142207472.statement:                "" => "req.http.Host ~ \"xyz.com&\""
      condition.142207472.type:                     "" => "REQUEST"
      condition.1923609354.name:                    "gadashboard" => "gadashboard"
      condition.1923609354.priority:                "10" => "10"
      condition.1923609354.statement:               "req.http.Host == \"dashboard.example.com\"" => "req.http.Host == \"dashboard.example.com\""
      condition.1923609354.type:                    "REQUEST" => "REQUEST"
      condition.2413415571.name:                    "XYZ" => ""
      condition.2413415571.priority:                "10" => "0"
      condition.2413415571.statement:               "req.http.Host ~ \"xyz.com$\"" => ""
      condition.2413415571.type:                    "REQUEST" => ""
      condition.986105586.name:                     "No Path" => "No Path"
      condition.986105586.priority:                 "5" => "5"
      condition.986105586.statement:                "req.url == \"/\" || req.url == \"\"" => "req.url == \"/\" || req.url == \"\""
      condition.986105586.type:                     "REQUEST" => "REQUEST"
      header.2216896588.action:                     "set" => ""
      header.2216896588.cache_condition:            "" => ""
      header.2216896588.destination:                "http.Host" => ""
      header.2216896588.ignore_if_set:              "false" => "false"
      header.2216896588.name:                       "Fasty abote" => ""
      header.2216896588.priority:                   "10" => "0"
      header.2216896588.request_condition:          "Fastly Example" => ""
      header.2216896588.response_condition:         "" => ""
      header.2216896588.type:                       "request" => ""
      header.2266005704.action:                     "" => "set"
      header.2266005704.cache_condition:            "" => ""
      header.2266005704.destination:                "" => "url"
      header.2266005704.ignore_if_set:              "" => "false"
      header.2266005704.name:                       "" => "Redirect / to /index.html"
      header.2266005704.priority:                   "" => "5"
      header.2266005704.regex:                      "" => <computed>
      header.2266005704.request_condition:          "" => "No Path"
      header.2266005704.response_condition:         "" => ""
      header.2266005704.source:                     "" => "\"/index\""
      header.2266005704.substitution:               "" => <computed>
      header.2266005704.type:                       "" => "request"
      header.2853613926.action:                     "" => "set"
      header.2853613926.cache_condition:            "" => ""
      header.2853613926.destination:                "" => "http.Host"
      header.2853613926.ignore_if_set:              "" => "false"
      header.2853613926.name:                       "" => "Fastly example"
      header.2853613926.priority:                   "" => "10"
      header.2853613926.regex:                      "" => <computed>
      header.2853613926.request_condition:          "" => "Fastly Example"
      header.2853613926.response_condition:         "" => ""
      header.2853613926.source:                     "" => "\"bucket-es-east-1\""
      header.2853613926.substitution:               "" => <computed>
      header.2853613926.type:                       "" => "request"
      header.3137338307.action:                     "set" => "set"
      header.3137338307.cache_condition:            "" => ""
      header.3137338307.destination:                "http.Host" => "http.Host"
      header.3137338307.ignore_if_set:              "false" => "false"
      header.3137338307.name:                       "TQN" => "TQN"
      header.3137338307.priority:                   "10" => "10"
      header.3137338307.request_condition:          "XYZ" => "XYZ"
      header.3137338307.response_condition:         "" => ""
      header.3137338307.source:                     "\"bucket-us-east-1\"" => "\"bucket-us-east-1\""
      header.3137338307.type:                       "request" => "request"
      header.3282513978.action:                     "" => "set"
      header.3282513978.cache_condition:            "" => ""
      header.3282513978.destination:                "" => "http.Host"
      header.3282513978.ignore_if_set:              "" => "false"
      header.3282513978.name:                       "" => "GA_Dashboard"
      header.3282513978.priority:                   "" => "10"
      header.3282513978.regex:                      "" => <computed>
      header.3282513978.request_condition:          "" => "gadashboard"
      header.3282513978.response_condition:         "" => ""
      header.3282513978.source:                     "" => "\"bucket-gadashboard.s3.amazon.aws.com\""
      header.3282513978.substitution:               "" => <computed>
      header.3282513978.type:                       "" => "request"
      header.3679560495.action:                     "set" => ""
      header.3679560495.cache_condition:            "" => ""
      header.3679560495.destination:                "url" => ""
      header.3679560495.ignore_if_set:              "false" => "false"
      header.3679560495.name:                       "Redirect / to /index.html" => ""
      header.3679560495.priority:                   "5" => "0"
      header.3679560495.request_condition:          "No Path" => ""
      header.3679560495.response_condition:         "" => ""
      header.3679560495.type:                       "request" => ""
      header.4253589739.action:                     "set" => ""
      header.4253589739.cache_condition:            "" => ""
      header.4253589739.destination:                "http.Host" => ""
      header.4253589739.ignore_if_set:              "false" => "false"
      header.4253589739.name:                       "GA_Dashboard" => ""
      header.4253589739.priority:                   "10" => "0"
      header.4253589739.request_condition:          "gadashboard" => ""
      header.4253589739.response_condition:         "" => ""
      header.4253589739.type:                       "request" => ""
     

Plan: 0 to add, 1 to change, 0 to destroy.

xff request setting default should be leave

If you add a request_setting but do not specify an xff parameter, it defaults to append, which actually inserts vcl to change X-Forwarded-For even if your request setting has nothing to do with that. Or if you have multiple request settings, one of which specifies xff, a subsequent request setting that doesn't include xff will override it.

The default should be leave, which does nothing. The fastly API reference does not specify a default: https://docs.fastly.com/api/config#request_settings

Splunk logging

There's no way to configure Splunk logging for Fastly with current fastly provider. Tho this is not GA yet.
Not sure how to deal with open source project and non GA features here.

Failure to activate a new version cannot be recovered from

Terraform Version

Terraform v0.11.5

Affected Resource(s)

Please list the resources as a list, for example:

  • fastly_service_v1

Terraform Configuration Files

{
  "resource": {
    "fastly_service_v1": {
      "fastly-cdn": {
        "domain": [
          {
            "name": "continuumtest--cdn-iiif.elifesciences.org"
          }
        ],
        "force_destroy": true,
        "name": "iiif--continuumtest",
        "backend": {
          "name": "iiif--continuumtest",
          "ssl_check_cert": true,
          "ssl_cert_hostname": "continuumtest--iiif.elifesciences.org",
          "address": "continuumtest--iiif.elifesciences.org",
          "use_ssl": true,
          "port": 443
        }
      }
    }
  }
}

Last Friday, some connection problem caused a timeout in an API call, at some point between the Version creation and its activation. I initially ignored this and restarted terraform apply, so I don't have logs about this failure.

Expected Behavior

The existing version should have been activated.

Actual Behavior

The step on the top is me enabling the version manually from the control panel. Executing terraform apply with a deactivated version seems to not cause any change to happen.

Steps to Reproduce

  1. terraform apply
  2. Interrupt after version creation but before it is enabled. I'll try also to deactivate it from the control panel on fastly.com
  3. terraform apply again, should ignore the deactivated state assuming this is fine.

It is also possible the version has been deactivated for some reason, but I cannot find that event in the control panel which makes the case for it never being activated.

[fastly] [fastly_service_v1] ssl_check_cert always set to true

This issue was originally opened by @mtougeron as hashicorp/terraform#14599. It was migrated here as part of the provider split. The original body of the issue is below.


With the fastly_service_v1 resource I'm finding that it always sets the ssl_check_cert for the backend to true.

 $> terraform --version
Terraform v0.9.5

The terraform code is:

provider "fastly" {
  api_key = "${module.fastly.api_key}"
}

resource "fastly_service_v1" "default" {
  name        = "tf-bug-example"
  default_ttl = 86400

  domain {
    name = "tf-bug-example.tubemogul.com"
  }

  backend {
    name                  = "tf-bug-example"
    address               = "origin.tf-bug-example.tubemogul.com"
    auto_loadbalance      = true
    port                  = 80
    ssl_check_cert        = "false"
    between_bytes_timeout = 10000
    connect_timeout       = 1000
    first_byte_timeout    = 15000
    max_conn              = 200
    weight                = 100
  }

  force_destroy = true
}

module "fastly" {
  source = "../../../modules/fastly"
  service-name = "tf-bug-example"
}

When I run terraform apply the output is:

$> terraform apply
fastly_service_v1.default: Creating...
  active_version:                          "" => "<computed>"
  backend.#:                               "0" => "1"
  backend.222562095.address:               "" => "origin.tf-bug-example.tubemogul.com"
  backend.222562095.auto_loadbalance:      "" => "true"
  backend.222562095.between_bytes_timeout: "" => "10000"
  backend.222562095.connect_timeout:       "" => "1000"
  backend.222562095.error_threshold:       "" => "0"
  backend.222562095.first_byte_timeout:    "" => "15000"
  backend.222562095.max_conn:              "" => "200"
  backend.222562095.name:                  "" => "tf-bug-example"
  backend.222562095.port:                  "" => "80"
  backend.222562095.request_condition:     "" => ""
  backend.222562095.shield:                "" => ""
  backend.222562095.ssl_cert_hostname:     "" => ""
  backend.222562095.ssl_check_cert:        "" => "false"
  backend.222562095.ssl_hostname:          "" => ""
  backend.222562095.ssl_sni_hostname:      "" => ""
  backend.222562095.weight:                "" => "100"
  default_host:                            "" => "<computed>"
  default_ttl:                             "" => "86400"
  domain.#:                                "0" => "1"
  domain.3070654332.comment:               "" => ""
  domain.3070654332.name:                  "" => "tf-bug-example.tubemogul.com"
  force_destroy:                           "" => "false"
  name:                                    "" => "tf-bug-example"
fastly_service_v1.default: Still creating... (10s elapsed)
fastly_service_v1.default: Creation complete (ID: 34AauvDdZ...sPoDb5m0)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

When I run terraform plan after the resource has been created it shows:

$> terraform plan 
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

fastly_service_v1.default: Refreshing state... (ID: 34AauvDdZ...sPoDb5m0)
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

~ fastly_service_v1.default
    backend.222562095.address:                "" => "origin.tf-bug-example.tubemogul.com"
    backend.222562095.auto_loadbalance:       "" => "true"
    backend.222562095.between_bytes_timeout:  "" => "10000"
    backend.222562095.connect_timeout:        "" => "1000"
    backend.222562095.error_threshold:        "" => "0"
    backend.222562095.first_byte_timeout:     "" => "15000"
    backend.222562095.max_conn:               "" => "200"
    backend.222562095.name:                   "" => "tf-bug-example"
    backend.222562095.port:                   "" => "80"
    backend.222562095.request_condition:      "" => ""
    backend.222562095.shield:                 "" => ""
    backend.222562095.ssl_cert_hostname:      "" => ""
    backend.222562095.ssl_check_cert:         "" => "false"
    backend.222562095.ssl_hostname:           "" => ""
    backend.222562095.ssl_sni_hostname:       "" => ""
    backend.222562095.weight:                 "" => "100"
    backend.2933010275.address:               "origin.tf-bug-example.tubemogul.com" => ""
    backend.2933010275.auto_loadbalance:      "true" => "false"
    backend.2933010275.between_bytes_timeout: "10000" => "0"
    backend.2933010275.connect_timeout:       "1000" => "0"
    backend.2933010275.error_threshold:       "0" => "0"
    backend.2933010275.first_byte_timeout:    "15000" => "0"
    backend.2933010275.max_conn:              "200" => "0"
    backend.2933010275.name:                  "tf-bug-example" => ""
    backend.2933010275.port:                  "80" => "0"
    backend.2933010275.request_condition:     "" => ""
    backend.2933010275.shield:                "" => ""
    backend.2933010275.ssl_cert_hostname:     "" => ""
    backend.2933010275.ssl_check_cert:        "true" => "false"
    backend.2933010275.ssl_hostname:          "" => ""
    backend.2933010275.ssl_sni_hostname:      "" => ""
    backend.2933010275.weight:                "100" => "0"


Plan: 0 to add, 1 to change, 0 to destroy.

If I run terraform apply it continually modifies the record and updates the resource to a new version.

But if I change the resource to have ssl_check_cert = "true" when I next run terraform plan it shows no changes needed.

$> terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

fastly_service_v1.default: Refreshing state... (ID: 34AauvDdZ...sPoDb5m0)
No changes. Infrastructure is up-to-date.

Configure BigQuery logging endpoint through terraform.

Affected Resource(s)

  • fastly_service_v1

Feature Request

Configure logging endpoint for BigQuery through terraform.

Important Factoids

fastly_service_v1 currently supports endpoints:

  • S3 Buckets
  • Papertrail
  • Sumologic
  • GCS (Google Cloud Storage)
  • syslog
  • logentries

Additional endpoints offered by Fastly but unhandled in fastly_service_v1 appear to be:

  • BigQuery
  • Spacess (Digital Ocean)
  • ftp
  • Heroku Logplex
  • loggly
  • Scalyr

References

I couldn't find any GitHub issues or PRs in either this repo or elsewhere regarding this feature.

Here are Fastly's docs on their supported logging endpoints: https://docs.fastly.com/guides/streaming-logs/setting-up-remote-log-streaming

Here are the Terraform docs I landed on when looking for BigQuery logging support: https://www.terraform.io/docs/providers/fastly/r/service_v1.html

[fastly][fastly_service_v1] support vcl snippets

This issue was originally opened by @mtougeron as hashicorp/terraform#14600. It was migrated here as part of the provider split. The original body of the issue is below.


It would be great if the fastly_service_v1 resource supported the VCL Snippets. The way the fastly_service_v1 resource works now we have to update the entire VCL, including the boilerplate, in order to modify just part of the logic (e.g., a Header). This prevents us from being able to use the VCL Snippets and simplifying our code-base & workflow.

Cannot delete S3 logging endpoint with / in its name

Terraform Version

$ terraform -v
Terraform v0.11.8
+ provider.fastly v0.2.0

Affected Resource(s)

fastly_service_v1

Terraform Configuration Files

resource "fastly_service_v1" "dev" {
  name = "prefix/DEV"

  s3logging {
    name             = "prefix/DEV"
    bucket_name      = "fastly-logs"
    # ...
  }
}

Expected Behavior

Properly defined S3 logging endpoint can be deleted without issues.

Actual Behavior

404 is returned.

Steps to Reproduce

  1. Define Fastly service with S3 logging endpoint named prefix/xyz (see example above)
  2. Run terraform apply - at this stage everything should be fine
  3. Delete s3logging property from your *.tf file
  4. Run terraform apply again
Error: Error applying plan:

1 error(s) occurred:

* fastly_service_v1.dev: 1 error(s) occurred:

* fastly_service_v1.dev: 404 - Not Found

Important Factoids

I've just raised a bug in go-fastly, as I belive it should be fixed there: fastly/go-fastly#91

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.