-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
Another reproduction:
|
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.
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.
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.
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.
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.
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.
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.
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.
Handling of 404's should be fixed in #62 The automatic tainting of 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 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"]
} |
Closing this out now with the release of v0.1.0 |
When destroying a database and attempting to re-create
planetscale_database
, the API simply returns an error during the plan phase: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:
The text was updated successfully, but these errors were encountered: