fix: GCP data disk snapshot never refreshed after first stop cycle#389
Open
arnaud-robin wants to merge 1 commit into
Open
fix: GCP data disk snapshot never refreshed after first stop cycle#389arnaud-robin wants to merge 1 commit into
arnaud-robin wants to merge 1 commit into
Conversation
Owner
|
Thanks for this PR! Have you tested the fix yourself? |
Author
|
Yes I just tested it and the fix is working as intended. A new snapshot is created after each stop cycle and the data is restored as intended. |
Owner
|
Tested, reproduced the issue and it works with the fix. Thanks! Will merge soon after review comments are processed :) |
| * Unique version identifier for the snapshot. A new value forces creation | ||
| * of a fresh snapshot replacing the previous one. | ||
| */ | ||
| snapshotVersion?: string |
Owner
There was a problem hiding this comment.
This should be required, not optional, given the behavior identified. It will also avoid having checks for undefined in code - being cleaner
| const config = new pulumi.Config() | ||
| const volumeId = config.get("volumeId") | ||
| const additionalTags = config.getObject<string[]>("additionalTags") || [] | ||
| const snapshotVersion = config.get("snapshotVersion") |
Owner
There was a problem hiding this comment.
Suggested change
| const snapshotVersion = config.get("snapshotVersion") | |
| const snapshotVersion = config.require("snapshotVersion") |
| // and force replacement of snapshot if volumeId changes | ||
| deleteBeforeReplace: true, | ||
| replaceOnChanges: ["sourceDisk"], | ||
| replaceOnChanges: ["sourceDisk", "name"], |
Owner
There was a problem hiding this comment.
Not needed to replaceOnChanges name, changing name already causes a replacement: https://www.pulumi.com/registry/packages/gcp/api-docs/compute/snapshot/#inputs
| /** | ||
| * Unique version identifier forcing snapshot replacement when it changes. | ||
| */ | ||
| snapshotVersion?: pulumi.Input<string> |
Owner
There was a problem hiding this comment.
As in other comment: should be required
PierreBeucher
added
the
review comments waiting
GCP data disk snapshot was only created on the first instance stop and never updated afterwards, causing any data written after the first stop/start cycle to be lost on restart (PierreBeucher#388). The snapshot stack relied on replaceOnChanges: ["sourceDisk"] to take a fresh snapshot on each stop, a pattern inherited from AWS where a volume restored from snapshot gets a brand new random ID (vol-xxx), naturally triggering replacement. On GCP however the disk is identified by its name (<instance>-data) which stays identical across delete/restore cycles: Pulumi saw no diff on subsequent stops and silently kept the stale snapshot. Since GCP provides no naturally-changing input, introduce a synthetic one: provisioner now passes a unique snapshotVersion (timestamp) on every data snapshot provision, included in the snapshot name. GCP snapshot names are immutable so the name change forces Pulumi to replace the snapshot on every stop cycle.
arnaud-robin
force-pushed
the
gcp-datasnapshot-fix
branch
from
June 14, 2026 20:16
ee03c77 to
1a4979f
Compare
Author
|
Updated thanks to your comments |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GCP data disk snapshot was only created on the first instance stop and
never updated afterwards, causing any data written after the first
stop/start cycle to be lost on restart
The snapshot stack relied on replaceOnChanges: ["sourceDisk"] to take a
fresh snapshot on each stop, a pattern inherited from AWS where a volume
restored from snapshot gets a brand new random ID (vol-xxx), naturally
triggering replacement. On GCP however the disk is identified by its
name (-data) which stays identical across delete/restore
cycles: Pulumi saw no diff on subsequent stops and silently kept the
stale snapshot.
Since GCP provides no naturally-changing input, introduce a synthetic
one: provisioner now passes a unique snapshotVersion (timestamp) on
every data snapshot provision, included in the snapshot name. GCP
snapshot names are immutable so the name change forces Pulumi to
replace the snapshot on every stop cycle.
Fix #388