Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aviatrix_controller_security_group_management_config does not disable security group management when being destroyed #1204

Open
t-dever opened this issue Jan 26, 2022 · 1 comment

Comments

@t-dever
Copy link

t-dever commented Jan 26, 2022

Describe the problem

Please describe the issue you observed, and any steps we can take to reproduce it:

To Reproduce

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = ">=2.92.0"
    }
    aviatrix = {
      source = "AviatrixSystems/aviatrix"
      version = "2.21.0-6.6.ga"
    }
  }
}

provider "azurerm" {
  features {}
  skip_provider_registration = true
}

variable "application_key"{
  type = string
}

data "azurerm_client_config" "current" {}

resource "aviatrix_account" "azure_account" {
  account_name        = "travis-testing-1"
  cloud_type          = 8
  arm_subscription_id = data.azurerm_client_config.current.subscription_id
  arm_directory_id    = data.azurerm_client_config.current.tenant_id
  arm_application_id  = data.azurerm_client_config.current.client_id
  arm_application_key = var.application_key
}

resource "aviatrix_controller_security_group_management_config" "security_group_management" {
  depends_on = [
    aviatrix_account.azure_account
  ]
  account_name                     = "travis-testing-1"
  enable_security_group_management = true
}

What did you do? Describe in your own words.

Applying the above terraform code works for enabling security group management. When destroying the code it will remove the security group management from state but it will not "Disable" the security group management. Therefore, deleting the account will fail since it's still configured for security group management.

If possible, provide steps to reproduce the behavior:

  1. terraform init
  2. terraform apply -var=application_key="<insert application key>"
  3. terraform applies everything correctly
  4. terraform apply -destroy
  5. Terraform successfully destroys the security group management resource, however it doesn't disable it. Therefore, fails to destroy the account as well.

Expected behavior
When terraform removes the aviatrix_controller_security_group_management_config resource it should also disable it.

Additional data / screenshots
Include any relevant tf files.

Error Message:

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

Do you really want to destroy all resources?
  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

aviatrix_controller_security_group_management_config.security_group_management: Destroying... [id=13-84-247-218]
aviatrix_controller_security_group_management_config.security_group_management: Destruction complete after 0s
aviatrix_account.azure_account: Destroying... [id=travis-testing-1]
╷
│ Error: failed to delete Aviatrix Account: rest API delete_account_profile Post failed: [AVXERR-ACCOUNT-0015] Controller Security Group Management is enabled on this account [travis-testing-1]. Please disable Controller Security Group Management in order to delete this account.
│
│

If applicable, add screenshots to help explain your problem.

Environment:

  • Provider version: 2.21.0-6.6.ga
  • Terraform version: 1.1.4.
  • Aviatrix Controller version: 6.6

Additional context
What was the impact?

Unable to destroy configured resources in the controller.

Add any other context about the problem here.

@inc1t3Ful
Copy link
Contributor

Upon investigation, this behavior can be explained due to that current design, destroy does not do anything other than state removal, as you have observed. This is because the default value is currently different for cloud providers, for now.

We can make destroying this resource disable the management option, when the default behavior is false for all clouds, under the controller.

For now, a workaround for this is to use a variable for the setting, and you can have it default to true (to maintain workflow of having to just use terraform apply for initial setup).
For cleanup, you can pass the variable value as false at runtime in the CLI using -var (eg. terraform apply -var foo_variable_name=false), and then proceed with destroy as normal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants