mirror of https://github.com/pulumi/pulumi.git
013d0791ff
The current behavior of `pulumi import` for a particular resource is a bit strange. It was designed to generate the smallest usable set of input properties for a resource using the following algorithm: 1. Read the current inputs and state (I_c, S_c) from the provider 2. Copy required inputs from I_c to a new input set I_n 3. Run I_n through the provider's Check method with the old inputs set to I_c, erroring on validation failures 4. Diff I_n against S_c 5. Copy the values of any differing properties from I_c into I_n The most problematic pieces of this algorithm are (2) and (3). In these steps, the engine first disregards any optional inputs under the assumption that their values are not required in order for `Check` to succeed, and that if omitting these values would cause diffs that they will be copied over during (5). Unfortunately, the former assumption is false and the latter can generate code that is misleading. In the former case, some providers model mutually-exclusive properties as optional properties where exactly one must be set. This then causes Check to fail in (3), halting the import process. The errors this process produces are opaque to the user, and worse, there is no corrective action the user can take in order to unblock themselves. We can simplify the implementation of `pulumi import` and allow users to unblock themselves by eliminating the check/diff/copy, taking the inputs from the provider wholesale, and either eliminating the call to Check altogether or lowering Check failures to warnings instead of errors. With this approach, the user always ends up with a successfully imported resource, though the codegen'd definition may need modifications before the program successfully runs. Improvements in providers' calculation of accurate input sets can then be delivered incrementally with somewhat less urgency, as users are no longer blocked. A somewhat more radical alternative might be to skip storing the imported resources in the stack's state altogether and instead generate definitions that set the `import` resource option. This approach lowers the `pulumi import` command to a simple codegen step. Though this requires more work on the part of the user, it may fit more cleanly into our overall design, as it builds on top of existing features. This design also has the advantage of ensuring that a resource never ends up in a stack's state until its definition is accurate. |
||
|---|---|---|
| .. | ||
| deploytest | ||
| providers | ||
| builtins.go | ||
| deployment.go | ||
| deployment_executor.go | ||
| deployment_test.go | ||
| doc.go | ||
| import.go | ||
| manifest.go | ||
| plan.go | ||
| snapshot.go | ||
| snapshot_test.go | ||
| source.go | ||
| source_error.go | ||
| source_eval.go | ||
| source_eval_test.go | ||
| source_fixed.go | ||
| source_null.go | ||
| source_query.go | ||
| source_query_test.go | ||
| step.go | ||
| step_executor.go | ||
| step_generator.go | ||
| step_generator_test.go | ||
| target.go | ||