History

joeduffy 2362d45a5c Eliminate type redundancy Despite our good progress moving towards having an apitype package, where our exchange types live and can be shared among the engine and our services, there were a few major types that were still duplciated. Resource was the biggest example -- and indeed, the apitype varirant was missing the new Dependencies property -- but there were others, like Manfiest, PluginInfo, etc. These too had semi-random omissions. This change merges all of these types into the apitype package. This not only cleans up the redundancy and missing properties, but will "force the issue" with respect to keeping them in sync and properly versioning the information in a backwards compatible way. The resource/stack package still exists as a simple marshaling layer to and from the engine's core data types. Finally, I've made the controversial change to share the actual Deployment data structure at the apitype layer also. This will force us to confront differences in that data structure similarly, and will allow us to leverage the strong typing throughout to catch issues.		2018-02-28 12:44:55 -08:00
..
step1	Rename pulumi package to @pulumi/pulumi (#917 )	2018-02-12 13:13:13 -08:00
step2	Remove yarn.lock from .gitignore	2018-01-30 14:46:44 -08:00
step3	Remove yarn.lock from .gitignore	2018-01-30 14:46:44 -08:00
step4	Remove yarn.lock from .gitignore	2018-01-30 14:46:44 -08:00
step5	Remove yarn.lock from .gitignore	2018-01-30 14:46:44 -08:00
step6	Remove yarn.lock from .gitignore	2018-01-30 14:46:44 -08:00
README.md	Add a test case for delete-before-recreate	2017-12-13 10:47:18 -08:00
steps_test.go	Eliminate type redundancy	2018-02-28 12:44:55 -08:00

README.md

This test attempts to exhaustively test all interesting combinations of resource steps. This includes:

Same
Create
Update
Delete
CreateReplacement
DeleteReplaced

In addition to the ability to recover from failures. For example, there is a "pending deletion" capability that will remember resources that were meant to be deleted, but couldn't be, due to a failure partway through.

The test is broken into a series of steps that will be executed in order. Because the steps create different resources, we will end up with a specific sequence of CRUD operations that we will validate.

Step 1

Populate the world:

Create 4 resources, a1, b1, c1, d1. c1 depends on a1 via an ID property.

Checkpoint: a1, b1, c1, d1

Step 2

Same, Update, Same, Delete, Create:

Create 1 resource, a2, equivalent to the a1 in Step 1 (Same(a1, a2)).
Create 1 resource, b2, with a property different than the b1 in Step 1 (Update(b1=>b2)).
Create 1 resource, c2, equivalent to the c1 in Step 1 (Same(c1, c2)).
Elide d (Delete(d1)).
Create 1 resource, e2, not present in Step 1 (Create(e2)).

Checkpoint: a2, b2, c2, e2

Step 3

Replace a resource:

Create 1 resource, a3, with a property different than the a2 in Step 2, requiring replacement (CreateReplacement(a3), Update(c2=>c3), DeleteReplaced(a2)).
Elide b (Delete(b2)).
Create 2 resources, c3 and e3, equivalent to Step 2 (Same(c2, c3), Same(e2, e3)).

Checkpoint: a3, c3, e3

Step 4

Replace a resource (but this time, deleteBeforeReplace):

Create 1 resource, a4, equivalent to the a3 in Step 3 (Same(a3, a4)).
Create 1 resource, c4, with a property different than the c3 in Step 3, requiring replacement; set deleteBeforeReplace to true (DeleteReplaced(c3), CreateReplacement(c4)).
Create 1 resource, e4, equivlaent to the e3 in Step 3 (Same(e3, e4)).

Checkpoint: a4, c4, e4

Step 5

Fail during an update:

Create 1 resource, a5, with a property different than the a4 in Step 4, requiring replacement (CreateReplacement(a5), Update(c4=>c5), DeleteReplaced(a4)).
Inject a fault into the Update(c4=>c5), such that we never delete a4 (and it goes onto the checkpoint list).

Checkpoint: a5, c5, e5; pending delete: a4

Step 6

Delete everything:

Elide a (Delete(a5)).
Elide c (Delete(c)).
Elide e (Delete(e)).
Pending delete (Delete(a4)).

Checkpoint: empty