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

Refresh with RDS MariaDB after restoring from DB snapshot deletes instance #2910

Closed
ffMathy opened this issue Oct 22, 2023 · 5 comments
Closed
Assignees
Labels
area/refresh awaiting-feedback Blocked on input from the author customer/feedback Feedback from customers kind/bug Some behavior is incorrect or out of spec needs-repro Needs repro steps before it can be triaged or fixed resolution/no-repro This issue wasn't able to be reproduced

Comments

@ffMathy
Copy link

ffMathy commented Oct 22, 2023

What happened?

When you perform a pulumi refresh on a database created in RDS (a MariaDB instance) after you've restored it from a snapshot, it triggers a deletion.

Example

Any Pulumi code that produces a MariaDB database can repro this.

But the following steps are important:

  1. Take a snapshot of the created database.
  2. Delete the database, so its name can be used for a restore.
  3. Restore the snapshot into the database's name again, causing it to have the same name and endpoint as before.
  4. Run a pulumi refresh. Now it'll detect the database as deleted, although it should pull from the new database instead.

Output of pulumi about

CLI
Version 3.89.0
Go Version go1.21.1
Go Compiler gc

Plugins
NAME VERSION
nodejs unknown

Host
OS debian
Version 12.2
Arch aarch64

This project is written in nodejs: executable='/usr/local/bin/node' version='v18.18.2'

Pulumi locates its logs in /tmp by default

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

@ffMathy ffMathy added kind/bug Some behavior is incorrect or out of spec needs-triage Needs attention from the triage team labels Oct 22, 2023
@mikhailshilkov
Copy link
Member

Hi @ffMathy

I believe the property identifier is used as a key lookup for RDS Instances. Do you know if identifier matched for two instances in your case?

@mikhailshilkov mikhailshilkov added awaiting-feedback Blocked on input from the author and removed needs-triage Needs attention from the triage team labels Oct 24, 2023
@ffMathy
Copy link
Author

ffMathy commented Oct 25, 2023

Identifier was not set, so identifierPrefix was generated automatically by the Pulumi resource name.

Switching to aws-native was a workaround.

@mikhailshilkov mikhailshilkov added needs-repro Needs repro steps before it can be triaged or fixed and removed awaiting-feedback Blocked on input from the author labels Oct 28, 2023
@mnlumi mnlumi added the customer/feedback Feedback from customers label Nov 29, 2023
@corymhall
Copy link
Contributor

corymhall commented Apr 12, 2024

@ffMathy I've not been able to reproduce this issue, it's possible that the underlying root cause has been fixed since you originally reported this issue. Here is what I have used to try and reproduce:

import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx";

const vpc = new awsx.ec2.Vpc("Vpc", {
  natGateways: { strategy: "Single" },
  subnetStrategy: "Auto",
});

const subnetGroup = new aws.rds.SubnetGroup("db-subnet-group", {
  subnetIds: vpc.privateSubnetIds,
})

const db = new aws.rds.Instance("db", {
  allocatedStorage: 20,
  engine: "mariadb",
  engineVersion: "10.11",
  autoMinorVersionUpgrade: true,
  instanceClass: aws.rds.InstanceType.T3_Micro,
  manageMasterUserPassword: true,
  username: "admin",
  dbSubnetGroupName: subnetGroup.name,
})

And I followed your steps:

  1. Take a snapshot of the created database.
  2. Delete the database, so its name can be used for a restore.
  3. Restore the snapshot into the database's name again, causing it to have the same name and endpoint as before.
  4. Run a pulumi refresh. Now it'll detect the database as deleted, although it should pull from the new database instead.

When I ran the refresh it pulled the new database and did not show a deletion.

@t0yv0 t0yv0 removed their assignment Apr 12, 2024
@mjeffryes mjeffryes added the awaiting-feedback Blocked on input from the author label Apr 19, 2024
@corymhall corymhall removed their assignment Apr 26, 2024
@mjeffryes
Copy link
Member

@ffMathy Have you continued to see this behavior? I'm wondering if we should close this issue since it appears to work in the latest version or if there's something else we're missing in our attempts to reproduce it.

@mjeffryes mjeffryes self-assigned this May 7, 2024
@mjeffryes mjeffryes added the resolution/no-repro This issue wasn't able to be reproduced label May 7, 2024
@mjeffryes
Copy link
Member

I'm going to close this out with no-repro for now, but happy to re-open if this you're still encountering this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/refresh awaiting-feedback Blocked on input from the author customer/feedback Feedback from customers kind/bug Some behavior is incorrect or out of spec needs-repro Needs repro steps before it can be triaged or fixed resolution/no-repro This issue wasn't able to be reproduced
Projects
None yet
Development

No branches or pull requests

6 participants