5 Commits (bc31dbc179b04b277ca268dedd5f30fa83af90da)

Author	SHA1	Message	Date
Alisdair McDiarmid	a5b7394f9a	command/jsonplan: Add replace_paths ... The set of paths which caused a resource update to require replacement has been stored in the plan since 0.15.0 (#28201). This commit adds a simple JSON representation of these paths, allowing consumers of this format to determine exactly which paths caused the resource to be replaced. This representation is intentionally more loosely encoded than the JSON state serialization of paths used for sensitive attributes. Instead of a path step being represented by an object with type and value, we use a more-JavaScripty heterogenous array of numbers and strings. Any practical consumer of this format will likely traverse an object tree using the index operator, which should work more easily with this format. It also allows easy prefix comparison for consumers which are tracking paths. While updating the documentation to include this new field, I noticed that some others were missing, so added them too.	5 years ago
Alisdair McDiarmid	ff32fab41a	command/jsonplan: Fix sensitive/unknown crash ... When rendering the JSON plan sensitivity output, if the plan contained unknown collection or structural types, Terraform would crash. We need to detect unknown values before attempting to iterate them. Unknown collection or structural values cannot have sensitive contents accidentally displayed, as those values are not known until after apply. As a result we return an empty value of the appropriate type for the sensitivity mapping.	5 years ago
Alisdair McDiarmid	e27aacebf9	command/jsonplan: Add sensitive value mapping data ... Similar to `after_unknown`, `before_sensitive` and `after_sensitive` are values with similar structure to `before` and `after` which encode the presence of sensitive values in a planned change. These should be used to obscure sensitive values from human-readable output. These values follow the same structure as the `before` and `after` values, replacing sensitive values with `true`, and non-sensitive values with `false`. Following the `after_unknown` precedent, we omit non-sensitive `false` values for object attributes/map values, to make serialization more compact. One difference from `after_unknown` is that a sensitive complex value (collection or structural type) is replaced with `true`. If the complex value itself is sensitive, all of its contents should be obscured.	5 years ago
Martin Atkins	d512584497	command/jsonplan: Don't panic with mixtures of known/unknown/empty ... The omitUnknowns and unknownAsBool functions were previously trying hard to preserve the same collection types in the output as they had in the input, by attempting to keep everything matched up so that the results would be valid. Unfortunately, this turns out to be a harder problem than we originally thought: it was possible for a collection value going in to produce inconsistent element types out (and thus a panic) in the following situations: - when a collection with mixed known and unknown values was passed in to omitUnknowns. - when a collection of collections where the inner collections are a mixture of empty and not empty in unknownAsNull. The results of these functions are only used to marshal to JSON anyway, and JSON serialization can't distinguish between the three sequence types or the two mapping types, so in practice we can just standardize on converting all sequences to tuple and all mappings to object here and not change the resulting output at all, and then we don't have to worry about making sure all of the inner types get preserved exactly. A nice consequence of that relaxation is that we can now do what we originally wanted to do with unknownAsBool, and omit map keys and object attributes altogether if their values would've been false, producing a much more compact result. This is easiest to do now when there's only one known user of this JSON plan output, and we know that user will treat both false and omitted as the same here.	7 years ago
Kristin Laemmert	f00fcb90bf	mildwonkey/b-show-state (#20032) ... * command/show: properly marshal attribute values to json marshalAttributeValues in jsonstate and jsonplan packages was returning a cty.Value, which json/encoding could not marshal. These functions now convert those cty.Values into json.RawMessages. * command/jsonplan: planned values should include resources that are not changing * command/jsonplan: return a filtered list of proposed 'after' attributes Previously, proposed 'after' attributes were not being shown if the attributes were not WhollyKnown. jsonplan now iterates through all the `after` attributes, omitting those which are not wholly known. The same was roughly true for after_unknown, and that structure is now correctly populated. In the future we may choose to filter the after_unknown structure to _only_ display unknown attributes, instead of all attributes. * command/jsonconfig: use a unique key for providers so that aliased providers don't get munged together This now uses the same "provider" key from configs.Module, e.g. `providername.provideralias`. * command/jsonplan: unknownAsBool needs to iterate through objects that are not wholly known * command/jsonplan: properly display actions as strings according to the RFC, instead of a plans.Action string. For example: a plans.Action string DeleteThenCreate should be displayed as ["delete", "create"] Tests have been updated to reflect this. * command/jsonplan: return "null" for unknown list items. The length of a list could be meaningful on its own, so we will turn unknowns into "null". The same is less likely true for maps and objects, so we will continue to omit unknown values from those.	7 years ago