Terraform-provider-azurerm: Problem to define only one action in azurerm_storage_management_policy

[PeterUherek]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

• Terraform v0.12.8
• provider.azurerm v1.35.0

Terraform Configuration Files

resource "azurerm_resource_group" "testrg" {
  name     = "resourceGroupName"
  location = "westus"
}

resource "azurerm_storage_account" "testsa" {
  name                = "storageaccountname"
  resource_group_name = "${azurerm_resource_group.testrg.name}"

  location                 = "${azurerm_resource_group.testrg.location}"
  account_tier             = "Standard"
  account_replication_type = "LRS"
  account_kind             = "BlobStorage"
}

resource "azurerm_storage_management_policy" "testpolicy" {
  storage_account_id = "${azurerm_storage_account.testsa.id}"

  rule {
    name = "RemoveTestContainers"
    enabled = true
    filters {
      blob_types = ["blockBlob"]
      prefix_match = [
        "i-test",
        "p-test",
        "r-test"
      ]
    }
    actions {
      base_blob {
        delete_after_days_since_modification_greater_than = 3
      }
    }
  }
}

Expected Behavior

The resource azurerm_storage_management_policy should respect a definition of the a base_blob action. I define only the one action delete_after_days_since_modification_greater_than = 3 in base blob. I expect only the one action allowed in the life cycle management.

Actual Behavior

There are actually allowed the other two actions , tier_to_cool_after_days_since_modification_greater_than tier_to_archive_after_days_since_modification_greater_than, with zero values.

Steps to Reproduce

1. terraform apply

[shybbko]

Just to clarify - the definition:

    actions {
      base_blob {
        tier_to_cool_after_days_since_modification_greater_than = "7"
      }
    }

should result in this:

Move to cool storage after 7 days after blob last modification.

not this (current behaviour):

Move to cool storage after 7 days after blob last modification.
Move to archive storage after 0 days after blob last modification.
Delete 0 days after blob last modification.

[dgee2]

I have also hit this bug in uk south. It is causing me to not be able to deploy at all as tierToArchive is not supported in uk south yet.

Error: Error creating Azure Storage Management Policy "/subscriptions/**********************************/resourceGroups/****************/providers/Microsoft.Storage/storageAccounts/*************": storage.ManagementPoliciesClient#CreateOrUpdate: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidManagementPolicyRule" Message="ManagementPolicy rule ******* is invalid. Invalid value for parameter : baseBlob, tierToArchive is not supported in this region currently"

[aagoldingay]

I have been able to deploy the following, which allows me to delete blobs before their tiers are changed:

    actions {
      base_blob {
        tier_to_archive_after_days_since_modification_greater_than = 2
        tier_to_cool_after_days_since_modification_greater_than = 2
        delete_after_days_since_modification_greater_than = 1
      }
    }

Hopefully this will help someone trying to do the same thing in regions that support all 3 actions.

[dgee2]

I have been able to deploy the following, which allows me to delete blobs before their tiers are changed:

    actions {
      base_blob {
        tier_to_archive_after_days_since_modification_greater_than = 2
        tier_to_cool_after_days_since_modification_greater_than = 2
        delete_after_days_since_modification_greater_than = 1
      }
    }

Hopefully this will help someone trying to do the same thing in regions that support all 3 actions.

This will only work in a region that supports all 3. Not all regions support all 3 but terraform attempts to apply them and gets an error back from Azure (correctly). UK South is the region that I know has this issue but I suspect this is also an issue in other regions

[gregjhogan]

This should be fixed ASAP because it by default puts in a policy that is enacted immediately (after 0 days) for omitted attributes (which should be allowed to be omitted) which can be destructive (delete after 0 days) or costly (archive after 0 days - which you will then have to pay to get back out of archive)

terraform apply literally shows that it is applying one thing, then applies something different (what it shows plus more)

For example, this says it is applying archive after 30 days, but it also adds delete after 0 days!!!
tf definition:

  rule {
    name    = "testrule"
    enabled = true
    filters {
      prefix_match = ["prefix/"]
      blob_types   = ["blockBlob"]
    }
    actions {
      base_blob {
        tier_to_archive_after_days_since_modification_greater_than = 30
      }
    }
  }

terraform apply output:

      + rule {
          + enabled = true
          + name    = "testrule"

          + actions {
              + base_blob {
                  + tier_to_archive_after_days_since_modification_greater_than = 30
                }
            }

          + filters {
              + blob_types   = [
                  + "blockBlob",
                ]
              + prefix_match = [
                  + "prefix/",
                ]
            }
        }
    }

what is actually applied:

        rule {
            enabled = true
            name    = "testrule"

            actions {
                base_blob {
                    delete_after_days_since_modification_greater_than          = 0
                    tier_to_archive_after_days_since_modification_greater_than = 30
                    tier_to_cool_after_days_since_modification_greater_than    = 0
                }
            }

            filters {
                blob_types   = [
                    "blockBlob",
                ]
                prefix_match = [
                    "prefix/",
                ]
            }
        }

[georgespatton]

We are affected by this bug too.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!