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

Need to execute destroy twice for deployment with postgresql_default_privileges #381

Closed
nicolamarangoni opened this issue Dec 1, 2023 · 2 comments

Comments

@nicolamarangoni
Copy link

Hi there,

I added default privileges on a schema for a specific role.
Now I need to execute terragrunt destroy twice to really destroy the deployment.

Thanks,
Nicola

Terraform Version

1.6.5

Affected Resource(s)

  • postgresql_role
  • postgresql_default_privileges

Terraform Configuration Files

resource "postgresql_database" "airflow" {
  name  = var.aws_rds_database
  owner = postgresql_role.airflow.name
}

resource "postgresql_role" "airflow" {
  name     = var.aws_rds_username
  login    = true
  password = random_password.airflow_rds.result
}

resource "postgresql_role" "airflow_ro" {
  name     = var.aws_rds_username_ro
  login    = true
  password = random_password.airflow_rds_ro.result
}

resource "postgresql_default_privileges" "airflow_ro" {
  database    = var.aws_rds_database
  owner       = var.aws_rds_username
  role        = var.aws_rds_username_ro
  schema      = "public"
  object_type = "table"
  privileges  = ["SELECT"]

  depends_on = [postgresql_database.airflow]
}

Expected Behavior

First terragrunt destroy successful

Actual Behavior

After the first destroy I get the error:
could not delete role role_name: pq: role "role_name" cannot be dropped because some objects depend on it
However, the terragrunt/terraform output of the first execution says that the postgresql_default_privileges resource has been successfully destroyed: postgresql_default_privileges.airflow_ro: Destruction complete after 5s
Actually the second attempt just destroy postgresql_role.airflow_ro, that was the only resource left by the first attempt.

Steps to Reproduce

  • Create a deployment with a postgresql_role and postgresql_default_privileges that assigns some default privileges to the role.
  • Destroy the deployment

Important Factoids

We only use terraform with terragrunt.

@cyrilgdn
Copy link
Owner

Hi @nicolamarangoni ,

Sorry for the late reply, if you still have this issue, it's not a provider bug but you simply need to configure dependencies between resources correctly in your code.

In your code example, you provide role name in postgresql_default_privileges directly with the variable where you should actually reference the postgresql_role resource instead (same for database, owner, etc...) , e.g.:

resource "postgresql_database" "airflow" {
  name  = var.aws_rds_database
  owner = postgresql_role.airflow.name
}

resource "postgresql_role" "airflow" {
  name     = var.aws_rds_username
  login    = true
  password = random_password.airflow_rds.result
}

resource "postgresql_role" "airflow_ro" {
  name     = var.aws_rds_username_ro
  login    = true
  password = random_password.airflow_rds_ro.result
}

resource "postgresql_default_privileges" "airflow_ro" {
  database    = postgresql_database.airflow.name
  owner       = postgresql_role.airflow.name
  role        = postgresql_role.airflow_ro.name
  schema      = "public"
  object_type = "table"
  privileges  = ["SELECT"]
}

Thanks to that, Terraform will now that your postgresql_default_privileges depends on the other resources and will destroy it before trying to destroy the roles & database.
Also, you don't need to define the depends_on for the database anymore.

I allow myself to close this issue but feel free to open it back if needed.

@nicolamarangoni
Copy link
Author

Hi @cyrilgdn , thank you for the answer.
Indeed I came to the same conclusion in December and corrected my deployment.
Best regards,

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