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

Destroy/replace of databases inconsistent #53

Open
rdvansloten opened this issue Dec 5, 2023 · 2 comments
Open

Destroy/replace of databases inconsistent #53

rdvansloten opened this issue Dec 5, 2023 · 2 comments

Comments

@rdvansloten
Copy link

When destroying a database and attempting to re-create planetscale_database, the API simply returns an error during the plan phase:

│ Error: Client Error
│ 
│   with planetscale_database.main,
│   on planetscale.tf line 1, in resource "planetscale_database" "main":
│    1: resource "planetscale_database" "main" {
│ 
│ Unable to read database, got error: error not_found: Not Found

Missing a resource should trigger a create during plan phase, not an error. (unless the database already exists outside state, but this is not the case.

Also, when deleting a database, any dependent planetscale_password is not tainted. During a follow-up run, the password will simply throw the same "Not found" error during the plan phase.

Configuration:

resource "planetscale_database" "main" {
  organization = var.planetscale_database["organization"]
  name         = var.planetscale_database["name"]
  plan         = "developer"
  region       = "eu-west"
}

resource "planetscale_password" "main" {
  organization = var.planetscale_database["organization"]
  database     = planetscale_database.main.name
  branch       = var.planetscale_database["branch"]
  name         = var.planetscale_database["password_name"]
}
@mscoutermarsh
Copy link
Member

Another reproduction:

  • create a password with terraform
  • delete it in UI
  • run terraform refresh
  • Will error instead of understanding it was removed

joemiller added a commit that referenced this issue Aug 20, 2024
re: #53

When a resource in the statefile has been deleted out of band, such as someone on the console or
using pscale cli deleting it, terraform should remove it from state and plan to recreate it.
However, we were treating 404s as fatal.

To solve this, the `Read()` method in each of our four resources now checks for 404 and removes the
resource from state so that terraform will offer to recreate the resource

This PR also adds initial acceptance test coverage for `database`, `password`, and `branch`
resources, including tests for the out-of-band deletion handling fixed by this PR. The `backup`
resource is currently not working and so tests for it will be added in later PRs.
joemiller added a commit that referenced this issue Aug 20, 2024
re: #53

When a resource in the statefile has been deleted out of band, such as someone on the console or
using pscale cli deleting it, terraform should remove it from state and plan to recreate it.
However, we were treating 404s as fatal.

To solve this, the `Read()` method in each of our four resources now checks for 404 and removes the
resource from state so that terraform will offer to recreate the resource

This PR also adds initial acceptance test coverage for `database`, `password`, and `branch`
resources, including tests for the out-of-band deletion handling fixed by this PR. The `backup`
resource is currently not working and so tests for it will be added in later PRs.
joemiller added a commit that referenced this issue Aug 20, 2024
re: #53

When a resource in the statefile has been deleted out of band, such as someone on the console or
using pscale cli deleting it, terraform should remove it from state and plan to recreate it.
However, we were treating 404s as fatal.

To solve this, the `Read()` method in each of our four resources now checks for 404 and removes the
resource from state so that terraform will offer to recreate the resource

This PR also adds initial acceptance test coverage for `database`, `password`, and `branch`
resources, including tests for the out-of-band deletion handling fixed by this PR. The `backup`
resource is currently not working and so tests for it will be added in later PRs.
joemiller added a commit that referenced this issue Aug 20, 2024
re: #53

When a resource in the statefile has been deleted out of band, such as someone on the console or
using pscale cli deleting it, terraform should remove it from state and plan to recreate it.
However, we were treating 404s as fatal.

To solve this, the `Read()` method in each of our four resources now checks for 404 and removes the
resource from state so that terraform will offer to recreate the resource

This PR also adds initial acceptance test coverage for `database`, `password`, and `branch`
resources, including tests for the out-of-band deletion handling fixed by this PR. The `backup`
resource is currently not working and so tests for it will be added in later PRs.
joemiller added a commit that referenced this issue Aug 21, 2024
re: #53

When a resource in the statefile has been deleted out of band, such as someone on the console or
using pscale cli deleting it, terraform should remove it from state and plan to recreate it.
However, we were treating 404s as fatal.

To solve this, the `Read()` method in each of our four resources now checks for 404 and removes the
resource from state so that terraform will offer to recreate the resource

This PR also adds initial acceptance test coverage for `database`, `password`, and `branch`
resources, including tests for the out-of-band deletion handling fixed by this PR. The `backup`
resource is currently not working and so tests for it will be added in later PRs.
joemiller added a commit that referenced this issue Aug 21, 2024
re: #53

When a resource in the statefile has been deleted out of band, such as someone on the console or
using pscale cli deleting it, terraform should remove it from state and plan to recreate it.
However, we were treating 404s as fatal.

To solve this, the `Read()` method in each of our four resources now checks for 404 and removes the
resource from state so that terraform will offer to recreate the resource

This PR also adds initial acceptance test coverage for `database`, `password`, and `branch`
resources, including tests for the out-of-band deletion handling fixed by this PR. The `backup`
resource is currently not working and so tests for it will be added in later PRs.
joemiller added a commit that referenced this issue Aug 21, 2024
re: #53

When a resource in the statefile has been deleted out of band, such as someone on the console or
using pscale cli deleting it, terraform should remove it from state and plan to recreate it.
However, we were treating 404s as fatal.

To solve this, the `Read()` method in each of our four resources now checks for 404 and removes the
resource from state so that terraform will offer to recreate the resource

This PR also adds initial acceptance test coverage for `database`, `password`, and `branch`
resources, including tests for the out-of-band deletion handling fixed by this PR. The `backup`
resource is currently not working and so tests for it will be added in later PRs.
joemiller added a commit that referenced this issue Aug 29, 2024
re: #53

When a resource in the statefile has been deleted out of band, such as someone on the console or
using pscale cli deleting it, terraform should remove it from state and plan to recreate it.
However, we were treating 404s as fatal.

To solve this, the `Read()` method in each of our four resources now checks for 404 and removes the
resource from state so that terraform will offer to recreate the resource

This PR also adds initial acceptance test coverage for `database`, `password`, and `branch`
resources, including tests for the out-of-band deletion handling fixed by this PR. The `backup`
resource is currently not working and so tests for it will be added in later PRs.
@joemiller
Copy link
Member

joemiller commented Aug 29, 2024

Handling of 404's should be fixed in #62

The automatic tainting of planetscale_password after a planetscale_database is still an open issue, and I will likely leave this issue open as we determine how to handle this.

In the meantime, you should be able to trigger a recreation of the password when the database is deleted/recreated by using an attribute from the database resource as an input to the password resource, creating a link in the state model, eg:

Starting from your example, doing this instead:

resource "planetscale_database" "main" {
  organization = var.planetscale_database["organization"]
  name         = var.planetscale_database["name"]
  plan         = "developer"
  region       = "eu-west"
}

resource "planetscale_password" "main" {
  organization = var.planetscale_database["organization"]
  database     = planetscale_database.main.name
  branch       = planetscale_database.main.default_branch
  name         = var.planetscale_database["password_name"]
}

Part of the issue is that passwords are really connected to branches not databases. For the default_branch case the above example with only db + password resources it would then make sense to use the default_branch attr from the database to make the linkage.

Or, when using db + branch + password:

resource "planetscale_database" "main" {
  organization = var.planetscale_database["organization"]
  name         = var.planetscale_database["name"]
  plan         = "developer"
  region       = "eu-west"
}

resource "planetscale_branch" "my-branch" {
  name          = "mybranch"
  organization  = var.planetscale_database["organization"]
  database      = planetscale_database.main.name
  parent_branch = planetscale_database.main.default_branch
}

resource "planetscale_password" "my-branch" {
  organization = var.planetscale_database["organization"]
  database     = planetscale_database.main.name
  branch       = planetscale_branch.my-branch.name
  name         = var.planetscale_database["password_name"]
}

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

3 participants