cannot enable brotli without impacting image optimization

[querry43]

Terraform Version

Terraform v1.2.5
on darwin_arm64

Affected Fastly Terraform Resource(s)

Please list the affected resources, for example:

• fastly_service_vcl

Terraform Configuration Files

resource fastly_service_vcl user_content {
  product_enablement {
    brotli_compression = true
  }
  ...
}

Expected Behavior

Terraform should only attempt to enable brotli compression.

Actual Behavior

The other parameters of product_enablement default, including image_optimizer. Our service does not allow us to enable or disable image optimization via the api so setting image_oprimizer = true is not an option. When we apply, it is unclear if optimization will be disabled.

ex:

      + product_enablement {
          + brotli_compression = true
          + domain_inspector   = false
          + image_optimizer    = false
          + name               = (known after apply)
          + origin_inspector   = false
          + websockets         = false
        }

Steps to Reproduce

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

1. terraform apply

Important Factoids (optional)

Is there anything atypical about your account or set up that we should know?

[Integralist]

Hi @querry43

Thanks for opening this issue. I completely understand.

It's an unfortunate design because of the ambiguity involved and the added complexity tied to the underlying Product Enablement Fastly API endpoints.

i.e. Having access to a product (such as image_optimizer) on your account doesn't necessarily mean you have the permissions to programmatically enable/disable that product via the Fastly API.

I'm going to do some further research into the Terraform design but I don't know if there is much I can do in the way of the current implementation. So what I will probably end up doing is adding to the Terraform documentation the following information to try and make it clearer for users in the future to understand what exactly will happen with regards to the product_enablement block.

I'll describe below the CRUD (Create, Read, Update, Delete) flows so you have a better understanding of what the Fastly Terraform provider is doing under the hood, and hopefully, that will help alleviate your concerns about accidentally disabling the Image Optimizer product on your account.

Summary

From what I understand you don't have the correct permissions to programmatically enable/disable Image Optimizer, and you're adding the product_enablement block for the first time with just brotli_compression = true configured.

If I have that all correct, then although the plan shows image_optimizer = false it shouldn't result in Image Optimizer being disabled because when the Terraform provider calls its Create function it will only make API calls to enable products (i.e. only make API calls for those products assigned true).

Create

When defining the product_enablement block, if you only set one attribute (e.g. brotli_compression), then the Create function inside the provider will check if the value is set to true.

Only if the product attribute (e.g. brotli_compression) is set to true will the provider attempt to enable the product.

If a product is not defined in the config, it will be given a default value of false, meaning none of those products will be 'disabled' it just means as far as Terraform creating the product_enablement block for the first time, it will only attempt to enable products that have been defined and assigned the value true.

Read

The Read function is used to update the Terraform state file. The Terraform provider calls the Fastly API to identify if a product is enabled or not, and it will assign the relevant true or false values to the state file.

If the Terraform configuration doesn't align with what the state file determines is how things are set up in the 'real world', then the Terraform plan/apply will indicate this in its diff when it compares the state file to your config file.

Update

The Update function checks to see if the product has a different value to what it was set to originally (e.g. have you changed a product from true to false or vice-versa) and if it has been modified, then the value assigned to a product is compared to see if it's set to true or false.

If it's set to true, then the provider will attempt to call the Fastly API to 'enable' that product. Otherwise, if the value is set to false, then the provider will attempt to call the Fastly API to 'disable' that product.

The key bit here is the 'entitlement' to call the Fastly API. Some customers don't have access to programmatically enable/disable products. Products have to then be set up manually by Fastly customer support.

If you do have programmatic access to the Product Enablement APIs, then you should ensure the correct value is assigned in your Terraform configuration to avoid accidentally disabling a product.

If you're unsure about whether you have API access, then I would strongly recommend reaching out to [email protected] to have them review your account settings and confirm this.

NOTE: I need to do some more investigation here as from my recent testing it looks like the Update function is never called and any changes to the product_enablement block actually result in the Delete function being called followed by the Create function.

UPDATE: I've identified a bug in the provider which means the product_enablement block is always deleted, then created (rather than just updated). But as we're planning on rewriting the Terraform provider it's likely this will be fixed in the rewrite as otherwise fixing this will be a breaking interface change.

Delete

When deleting the product_enablement block from your Terraform configuration, the Delete function inside the provider will attempt to disable each product.

Now if the API returns an error, then that error will be returned to the user and consequently the terraform apply will fail. But, the error is only returned if it is not an error related to permissions/access to the API endpoint itself.

This means, that if you delete the product_enablement block and you don't have access to disable Image Optimizer, then the error that is returned from the API to the Terraform provider will indicate that it failed because you don't have access to disable the product and that particular error will be ignored by the provider, subsequently allowing the terraform apply to complete successfully.

[Integralist]

Hi @querry43

I've opened the following PR #763 to try and address some issues I noticed in the original implementation.

If you would like to try it out you can pull the code locally, run make build and following the instructions (basically export an environment variable to where you normally run terraform apply and run terraform init to ensure the local build of the provider is used).