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

[Bug]: snowflake_database with the from_database won't migrate automatically for 0.93 #2978

Closed
1 task
kanomaxb opened this issue Aug 5, 2024 · 3 comments
Closed
1 task
Assignees
Labels
bug Used to mark issues with provider's incorrect behavior

Comments

@kanomaxb
Copy link

kanomaxb commented Aug 5, 2024

Terraform CLI Version

1.2.6

Terraform Provider Version

0.93

Terraform Configuration

resource "snowflake_database" "test" {
  name = "VERY_IMPORTANT_DB"
  data_retention_time_in_days = 7
  from_database = "THE_MODEL_DB"
}

Category

category:resource

Object type(s)

resource:database

Expected Behavior

I'm trying to upgrade from 0.92 to 0.93.

I have the old snowflake_database resource, with the from_database parameter set.

The migration guide says:

If you had from_database set, it should migrate automatically.

Actual Behavior

I'm not sure what it means, that it should migrate automatically.
If I just change the version, it says "Unsupported argument".
If I change the version and remove the from_database param, it says "failed to upgrade the state with database created from database".

What should I do to achieve the "automatic upgrade" mentioned in the migration guide?

Steps to Reproduce

.

How much impact is this issue causing?

Medium

Logs

No response

Additional Information

No response

Would you like to implement a fix?

  • Yeah, I'll take it 😎
@kanomaxb kanomaxb added the bug Used to mark issues with provider's incorrect behavior label Aug 5, 2024
@kanomaxb kanomaxb changed the title [Bug]: [Bug]: snowflake_database with the from_database won't migrate automatically for 0.93 Aug 5, 2024
@sfc-gh-jcieslak
Copy link
Collaborator

Hey @kamilamarcinekpgs
That's a documentation error; I'll fix it. As from_database is database cloning, which is not currently supported, the only way is to remove the database from the state terraform state rm -> upgrade to the newer version -> import the database.

@sfc-gh-jcieslak sfc-gh-jcieslak self-assigned this Aug 6, 2024
sfc-gh-jcieslak added a commit that referenced this issue Aug 8, 2024
## Changes
- #2978 (adjust migration guide)
- Fix database tests (remove tests for state upgraders, because they
were incorrect and document step-by-step process for manual testing; I
went through all of it)
- Introduce a new parameter to address #2826 and test it
- added a drop with retries just to be sure, but I don't think it should
ever fail other than some kind of strange networking error between
database create and drop schema
- I opted to drop the schema after setting id, so if we manage to create
a database, but not drop the schema, the provider will print out a
warning message that the public schema couldn't be dropped and it should
be done manually. The other approaches I considered:
- Do it before setting ID, but that would mean the Terraform running
create again and failing on CREATE DATABASE (because it's already
there).
- Do it like right now, but make sure the public schema is gone in the
alter, but I didn't go for that, because it could lead to further
complications with (what is considered "after create"; after successful
create? how would we keep the state of create status? etc.).

---------

Co-authored-by: Jakub Michalak <jakub.michalak@snowflake.com>
@sfc-gh-jcieslak
Copy link
Collaborator

sfc-gh-jcieslak commented Sep 5, 2024

Hey 👋
Yesterday, we released a new version of the provider (v0.95.0) where the message after migrating with from_database should be more descriptive and I adjusted the migration guide.

@sfc-gh-jcieslak
Copy link
Collaborator

sfc-gh-jcieslak commented Oct 15, 2024

Closing due to long inactivity. Please, create another issue if you think the problem is still not resolved.

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

2 participants