DXE-3989 Property Activation Resource Does Not Update TF-State

[aweingarten]

Hi there,

Affected Resource(s)

Please list the resources as a list, for example:

• akamai_property_activation

Terraform Configuration Files

resource "akamai_property_activation" "my-property-activation" {
  property_id                    = akamai_property.my-property.id
  contact                        = ["me@me.com"]
  version                        = akamai_property.my-property.latest_version
  network                        = var.network
  auto_acknowledge_rule_warnings = true
}

When I run this my property's state is not updated

In subsequent runs I get the following in TF plan:

Note: Objects have changed outside of OpenTofu

OpenTofu detected the following changes made outside of OpenTofu since the
last "tofu apply" which may have affected this plan:
  # akamai_property.my-property has changed
  ~ resource "akamai_property" "my-property" {
        id                 = "prp_1123456"
        name               = "production"
      ~ staging_version    = 17 -> 18
        # (10 unchanged attributes hidden)
        # (1 unchanged block hidden)
    }

I have reproduced this from a CI-based build so I KNOW the state is not being manipulated by a person. When I checked the statefile I saw which suggests to me that at the end of that apply version 19 was activated.

"outputs": {
    "activation": {
      "value": {
        "activation_id": "atv_12323",
        "auto_acknowledge_rule_warnings": true,
        "compliance_record": [],
        "contact": [
          "me@me.com"
        ],
        "errors": "",
        "id": "prp_1062913:STAGING",
        "network": "STAGING",
        "note": "",
        "property_id": "prp_1062913",
        "rule_errors": [],
        "status": "ACTIVE",
        "timeouts": [],
        "version": 19,
        "warnings": ""
      },

However, when I look at my property in the state file I see that its still set to 18

  "my-property": {
      "value": {
        "contract_id": "me",
        "group_id": "grp_me",
        "hostnames": [
          {
            "cert_provisioning_type": "DEFAULT",
            "cert_status": [
              {
                "hostname": "_acme-challenge.production.edgejourney.dev",
                "production_status": "NEEDS_ACTIVATION",
                "staging_status": "DEPLOYED",
                "target": "ac.7bcf83a829a795097d7f559d36b3fcd9.production.edgejourney.dev.validate-akdv.net"
              }
            ],
            "cname_from": "production.edgejourney.dev",
            "cname_to": "production.edgejourney.dev.edgekey.net",
            "cname_type": "EDGE_HOSTNAME",
            "edge_hostname_id": "ehn_5631392"
          }
        ],
        "id": "prp_1062913",
        "latest_version": 19,
        "name": "production",
        "product_id": "prd_SPM",
        "production_version": 0,
        "property_id": null,
        "read_version": 0,
        "rule_errors": [],
        "rule_format": "v2024-02-12",
        "rule_warnings": [
          {
            "behavior_name": "",
            "detail": "Matching on `Request Type` requires thorough understanding of the way Akamai Edge servers process requests.  If you are unsure about how this will affect your property, please contact your Akamai Technical representative, and please test thoroughly on staging before activating on production.",
            "error_location": "#/rules/children/0/children/2/criteria/0",
            "instance": "",
            "status_code": 0,
            "title": "",
            "type": "https://problems.luna.akamaiapis.net/papi/v0/validation/validation_message.general_warning"
          },
          {
            "behavior_name": "",
            "detail": "HTTP/3 connection reuse lets clients re-use an open connection for any domain included in your certificate, even if these domains point to different origins. Most browsers will perform a DNS query to ensure there's an overlap in the domain's IP before reusing the connection. If you're using multiple certificates, specifically both Standard TLS and Enhanced TLS, don't include the same domain across them. If you do, an HTTP request to the domain that requires Enhanced TLS could be resolved using the less secure Standard TLS certificate, and vice-versa.",
            "error_location": "#/rules/children/1/children/1/behaviors/1",
            "instance": "",
            "status_code": 0,
            "title": "",
            "type": "https://problems.luna.akamaiapis.net/papi/v0/validation/validation_message.http3_enabled_warning_reuse"
          },
          {
            "behavior_name": "",
            "detail": "Enabling preload makes future downgrade to HTTP difficult.",
            "error_location": "#/rules/children/4/children/3/behaviors/0",
            "instance": "",
            "status_code": 0,
            "title": "",
            "type": "https://problems.luna.akamaiapis.net/papi/v0/validation/need_feature"
          }
        ],
        "rules":{abbreviated}
        "staging_version": 18,
        "version_notes": ""
      },

Expected Behavior

The activation should be updating the staging version in the state but for some reason is not.

Actual Behavior

Because TF thinks that the state is being manually edited its forcing un-necessary resource changes slowing down my builds.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example: you can see the build/ TF plans here: https://github.com/akamai-consulting/akamai-starterkit/actions/runs/9492787184/job/26199517994

Code is here: https://github.com/akamai-consulting/akamai-starterkit

[mstojanowski]

Hi @aweingarten ,

Thank you for raising this issue. It's under investigation now. We will get back to you when we know more.

Regards, Marcin

[mstojanowski]

@aweingarten,

We've managed to reproduce this situation. This is a known limitation of terraform, which can be overcome by running the terraform refresh command.

We'll improve the documentation on our end to better describe this situation.

Please try to use terraform refresh and let us know if this solves your issue.

Regards, Marcin

[aweingarten]

Hey @mstojanowski My understanding is that terraform refresh is deprecated and not recommended based on the official docs: https://developer.hashicorp.com/terraform/cli/commands/refresh

Warning: This command is deprecated, because its default behavior is unsafe if you have misconfigured credentials for any of your providers. See below for more information and recommended alternatives.

I can try to do terraform apply -refresh-only -auto-approve after each run as a temp work around outside a production setting, but that seems to be highly discouraged by the docs. I don't think its a real solution as it would mask config drift.

Running TF apply should result in stable TF state. If its not then that's breaking the TF model. This is a feature of TF not a limitation.

[wzagrajcz]

Hello @aweingarten Sorry for recommending deprecated solution. Based on https://developer.hashicorp.com/terraform/cli/commands/refresh Hashicorp currently suggest to use terraform apply -refresh-only as it gives a way to review changes that will be set into state.

The problem with staging_version and production_version fields is that they actually are not part of property itself but a property activation - after property is modified we do not know if they will got new value after activation (as activation is done by differet resource that is dependent by property). We see this as Terraform limitation because Terraform sets value for fields only after given resource has been processed, not once whole config has been processed. As a result, those fields are not updated. From perspective of property resurce and those fields we are actually facing a drift here and that's why we suggest to do state refresh. As a result we have no way to fix the issue that you mention. If you think it's better to don't have this fields at all in property resource rather then to have them with current behavior, please let us know.

Edit: Alternatively, if you simply need to know what are current values of staging_version and production_version after activation, you can add a datasource akamai_property (which also has those two fields) with explicite depends_on pointing to both activation resource. It should have correct values because it'll be executed after activations.

Best regards, Wojciech

[aweingarten]

yeah I empathize with the complexities here. My 2c is to remove the versions from the property resource and let them be managed by the activation resource instead. That should provide a much cleaner separation of concerns and make TF happy.

[wzagrajcz]

Hello @aweingarten Dropping those two fields is problematic from our perspective. Can you please write full use-case that you have, where those two fields values before refresh are causing problems?

Best regards, Wojciech