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

snowflake roles appear as deleted after upgrading from provider 0.84.1 to 0.85.0 #2460

Closed
jacobcbeaudin opened this issue Feb 2, 2024 · 11 comments
Assignees
Labels
bug Used to mark issues with provider's incorrect behavior

Comments

@jacobcbeaudin
Copy link
Contributor

jacobcbeaudin commented Feb 2, 2024

Terraform CLI and Provider Versions

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the
last "terraform apply" which may have affected this plan:

  # module.team_roles["A"].module.team_role.snowflake_role.role has been deleted
  - resource "snowflake_role" "role" {
        id      = "a"
      - name    = "A" -> null
        # (1 unchanged attribute hidden)
    }

  # module.team_roles["B"].module.team_role.snowflake_role.role has been deleted
  - resource "snowflake_role" "role" {
        id      = "b"
      - name    = "B" -> null
        # (1 unchanged attribute hidden)
    }

Unless you have made equivalent changes to your configuration, or ignored the
relevant attributes using ignore_changes, the following plan may include
actions to undo or respond to these changes.

─────────────────────────────────────────────────────────────────────────────

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create
  ~ update in-place
 <= read (data resources)

Terraform will perform the following actions:

  # module.team_roles["A"].module.team_role.snowflake_role.role will be created
  + resource "snowflake_role" "role" {
      + comment = "A ROLE"
      + id      = (known after apply)
      + name    = "A"
    }

  # module.team_roles["B"].module.team_role.snowflake_role.role will be created
  + resource "snowflake_role" "role" {
      + comment = "B ROLE"
      + id      = (known after apply)
      + name    = "B"
    }


Plan: 7 to add, 1 to change, 0 to destroy.

Warning: Account role not found; marking it as removed

  with module.team_roles["A"].module.team_role.snowflake_role.role,
  on ../../../modules/snowflake/role/main.tf line 1, in resource "snowflake_role" "role":
   1: resource "snowflake_role" "role" {

Account role name: "a", err: object does not exist

(and 6 more similar warnings elsewhere)

─────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't
guarantee to take exactly these actions if you run "terraform apply" now.

Terraform Configuration

terraform {

  required_version = ">= 1.7.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.33"
    }
    snowflake = {
      source  = "Snowflake-Labs/snowflake"
      version = "0.85.0"
    }
  }
}

provider "snowflake" {
  account       = local.snowflake_account_id
  authenticator = "JWT"
}

provider "snowflake" {
  alias         = "account_admin"
  role          = "ACCOUNTADMIN"
  account       = local.snowflake_account_id
  authenticator = "JWT"
}

provider "snowflake" {
  alias         = "security_admin"
  role          = "SECURITYADMIN"
  account       = local.snowflake_account_id
  authenticator = "JWT"
}

provider "snowflake" {
  alias         = "sys_admin"
  role          = "SYSADMIN"
  account       = local.snowflake_account_id
  authenticator = "JWT"
}

Expected Behavior

I expected my terraform plan to no changes besides deprecated resource warning. I am upgrading from provider version 0.84.1 to 0.85.0

Actual Behavior

Snowflake is saying that the roles it is managing have deleted outside of terraform. When I run SHOW ROLES; in snowsql, I see the roles that terraform is saying was deleted

Steps to Reproduce

  1. create a role using provider 0.84.1 or older
  2. upgrade to provider 0.85.0
  3. terraform init
  4. terraform plan

How much impact is this issue causing?

Medium

Logs

No response

Additional Information

No response

@jacobcbeaudin jacobcbeaudin added the bug Used to mark issues with provider's incorrect behavior label Feb 2, 2024
@philippeboyd
Copy link
Contributor

philippeboyd commented Feb 4, 2024

+1 with this; same issue while upgrading 0.84.1 to 0.85.0

@sfc-gh-jcieslak
Copy link
Collaborator

Hey @jacobcbeaudin @philippeboyd
Could you help with the steps to reproduce the error? I created a role in 0.84.1 and upgraded to 0.85.0 without any changes suggested by the terraform plan.
Tested config (also tested with lowercase):

resource "snowflake_role" "test" {
  name = "TEST_ROLE_TEST_UPGRADE"
}

@philippeboyd
Copy link
Contributor

@sfc-gh-jcieslak honestly not sure how to reproduce it on my end, it happened with a role inside a module, but I'm putting my money on this commit specifically

I'll have to reverse engineer the commit to understand what could've gone wrong...

@jacobcbeaudin
Copy link
Contributor Author

Hey @jacobcbeaudin @philippeboyd Could you help with the steps to reproduce the error? I created a role in 0.84.1 and upgraded to 0.85.0 without any changes suggested by the terraform plan. Tested config (also tested with lowercase):

resource "snowflake_role" "test" {
  name = "TEST_ROLE_TEST_UPGRADE"
}

To clarify, the roles in question were not initially created with version 0.84.1 of the Snowflake provider; they were created with an even earlier version, and since then, we have been consistently upgrading the provider across several versions up to 0.85.0. This iterative upgrade process over multiple versions might be contributing to the observed behavior.

Additionally, I should mention that our Terraform configuration uses an S3 remote backend for state storage. This detail might also play a role in how state discrepancies and external changes are detected by Terraform.

Given these nuances—specifically the use of an earlier version for initial role creation and the continual provider upgrades, as well as the configuration of an S3 remote backend—could these factors be influencing the issue at hand?

@sfc-gh-jcieslak
Copy link
Collaborator

@sfc-gh-jcieslak honestly not sure how to reproduce it on my end, it happened with a role inside a module, but I'm putting my money on this commit specifically

So, we already checked that commit a few times and couldn't spot any difference in the inner workings of the provider.

To clarify, the roles in question were not initially created with version 0.84.1 of the Snowflake provider; they were created with an even earlier version, and since then, we have been consistently upgrading the provider across several versions up to 0.85.0.

We also tried to upgrade from earlier versions like v0.80.0, but still couldn't reproduce the described behavior. Please, try to provide working steps to reproduce the issue. Otherwise, I can only suggest importing the state back with Terraform CLI. It's described in our latest migration guide for the grants, but that applies to any other resource. It's here - if you don't have those resources in your state you can start with 3rd point to import the state back.

In the case of the external state storage, maybe @sfc-gh-swinkler knows if that could be the root cause, but I'm assuming that it shouldn't be any different than local state management.

@jacobcbeaudin
Copy link
Contributor Author

@sfc-gh-jcieslak honestly not sure how to reproduce it on my end, it happened with a role inside a module, but I'm putting my money on this commit specifically

So, we already checked that commit a few times and couldn't spot any difference in the inner workings of the provider.

To clarify, the roles in question were not initially created with version 0.84.1 of the Snowflake provider; they were created with an even earlier version, and since then, we have been consistently upgrading the provider across several versions up to 0.85.0.

We also tried to upgrade from earlier versions like v0.80.0, but still couldn't reproduce the described behavior. Please, try to provide working steps to reproduce the issue. Otherwise, I can only suggest importing the state back with Terraform CLI. It's described in our latest migration guide for the grants, but that applies to any other resource. It's here - if you don't have those resources in your state you can start with 3rd point to import the state back.

In the case of the external state storage, maybe @sfc-gh-swinkler knows if that could be the root cause, but I'm assuming that it shouldn't be any different than local state management.

Thank you for the suggestions and guidance, @sfc-gh-jcieslak.

After attempting to replicate the issue in a separate environment without success, it appears that the problem might be unique to the specific state or configuration of the original environment. I also tried following the migration guide to import the role back into the state, but unfortunately, I was unable to import the role successfully.

Given the urgency to resolve the issue and considering the inability to replicate or rectify it through suggested methods, I opted to delete the role outside of Terraform and then re-create it. This approach was not ideal, but it allowed us to quickly restore the desired state within a 10-minute maintenance window.

@sfc-gh-jcieslak
Copy link
Collaborator

Could you share the details on error messages or commands that you were running during unsuccessful imports? We would like to take a look at them and adjust migration notes if needed.

@jacobcbeaudin
Copy link
Contributor Author

jacobcbeaudin commented Feb 7, 2024

Could you share the details on error messages or commands that you were running during unsuccessful imports? We would like to take a look at them and adjust migration notes if needed.

Unfortunately, I no longer have access to those logs.

@sfc-gh-jcieslak
Copy link
Collaborator

Hey @jacobcbeaudin
As we don't have anything to work on (I mean lost logs) we can close this issue, right?

@jacobcbeaudin
Copy link
Contributor Author

Hey @jacobcbeaudin As we don't have anything to work on (I mean lost logs) we can close this issue, right?

Yes, feel free to close this issue

@pwhittlesea
Copy link

pwhittlesea commented Oct 3, 2024

I know this has been closed for a while but I have been banging my head against this issue so I thought people would appreciate the context I have found.

The cause of the issue here for us is a combination of 2 things.

The first of those is that we renamed a role.
It used to be called READER_PROD and was renamed to READER.

This resulted in our state looking like this:

{
    "mode": "managed",
    "type": "snowflake_role",
    "name": "role",
    "provider": "provider[\"registry.terraform.io/snowflake-labs/snowflake\"]",
    "instances": [
        {
            "index_key": 0,
            "schema_version": 0,
            "attributes": {
                "comment": "The comment for the role",
                "id": "READER_PROD",
                "name": "READER",
                "tag": []
            }
        }
    ]
}

So a previous version (v0.66.2) of the Snowflake Terraform provider changed the name but not the id of the resource.

Then in this commit in file pkg/resources/role.go the code for reading a role changed from getting the resource by name (if set) to only getting the resource by ID.

- id := d.Id()
- // If the name is not set (such as during import) then use the id
- name := d.Get("name").(string)
- if name == "" {
- 	name = id
- }
- builder := snowflake.NewRoleBuilder(db, name)
- role, err := builder.Show()
+ client := sdk.NewClientFromDB(db)
+ id := helpers.DecodeSnowflakeID(d.Id()).(sdk.AccountObjectIdentifier)
+ accountRole, err := client.Roles.ShowByID(ctx, sdk.NewShowByIdRoleRequest(id))

These two things added together results in the situation outlined in this issue.
Terraform cannot find the role anymore and it wants to recreate it.

We do not get this issue on roles that have not been renamed as the state has id and name as the same value.

I think the resolution here is for me to manually change the Terraform state to set id to be equal to name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Used to mark issues with provider's incorrect behavior
Projects
None yet
Development

No branches or pull requests

4 participants