79c5d97afa
It's often the case that we want to move or rename resources in our Pulumi programs. Doing so can result in a change in the resource's URN, which means that Pulumi will, by default, see the move as a deletion of the old resource and a creation of the new resource. We can tell Pulumi that a resource has been renamed by using *aliases*, whereby a resource can be annotated with its previous URNs. Pulumi will then use these URNs in several places: * When looking for a resource's previous state, Pulumi will try to find it using the new URN first and any aliases second. * When writing out a new snapshot, Pulumi will *normalize* all URNs (e.g. those in provider, parent and dependency references) to remove aliases and replace them with the new URNs they resolve to. Alas, a familiar story presents itself in the second case -- Pulumi does not currently normalize `DeletedWith` references. This can result in snapshot integrity errors as Pulumi leaves stale references in the snapshot before writing it. This commit addresses this omission, using the now-preferred `GetAllDependencies` method introduced in #17320 to hopefully stop this from happening again in this part of the codebase. Fixes #17614 |
||
|---|---|---|
| .. | ||
| README.md | ||
| fixture.go | ||
| plan.go | ||
| pretty.go | ||
| program.go | ||
| provider.go | ||
| reprogen.go | ||
| resource.go | ||
| snapshot.go | ||
| stack.go | ||
README.md
(lifecycle-fuzzing)=
Fuzzing
Snapshot integrity errors are very problematic when they occur and can be hard to spot and prevent. To this end, a subset of the lifecycle test suite uses a combination of fuzzing and property-based testing via the Rapid Go library to randomly generate snapshots and programs to see whether or not it is possible to trigger a snapshot integrity error.
While snapshot integrity issues often happen as part of a chain of snapshot operations (e.g. the execution of multiple steps in a deployment), the precursor to any error state will always be a valid snapshot. Thus, rather than having to generate random chains of operations, we can instead simplify the problem to generating valid starting snapshots and then executing a single random operation on them. The strategy we employ is thus as follows:
-
Generate a snapshot (snapshot.go) consisting of a random set of resources (resource.go), including appropriate providers. Resources may randomly depend on each other, and may have random properties, such as whether they are custom resources or components, pending replacement, and so on.
-
Generate a program (program.go) from the previously generated snapshot. The program may choose to register any subset (including none) of the resources in the snapshot, as well as any set of new resources before, in between and after those specified in the snapshot. Resources from the snapshot that are registered may be copied as-is or registered with different properties.
-
Generate a set of provider implementations for the program (provider.go). Provider operations such as , , etc. may be configured to fail randomly, or return one of a set of random results (e.g. an update vs a replace for
Diff), on a per-resource basis. -
Generate an operation (one of
preview,up,refreshanddestroy) and associated configuration (such as a list of--targets), known in the test suite as a plan to execute (plan.go). -
Combine the snapshot, program, providers and plan to form a fixture (fixture.go) and execute it. If the operation yields a valid snapshot, the test passes, whether the operation completes successfully or not. If an invalid snapshot is produced, the test fails and the reproducing combination of snapshot, program, providers and plan is returned for debugging.
In the event that a failing test case is found, the reproducing fixture will be pretty printed to the screen and code for a reproducing test case will be written to a file to aid in debugging. See fixture.go and reprogen.go for more details.
:::{note}
By default, reproduction test files will be written to a temporary directory. A
specific directory can be configured using the
PULUMI_LIFECYCLE_TEST_FUZZING_REPRO_DIR environment variable.
:::