This package contains functionality around formatting and displaying the JSON
structured output produced by adding the -json flag to various OpenTofu
commands.
OpenTofu Structured Plan Renderer
As of January 2023, this package contains only a single structure: the
Renderer.
The renderer accepts the JSON structured output produced by the
tofu show <plan-file> -json command and writes it in a human-readable
format.
Implementation details and decisions for the Renderer are discussed in the
following sections.
Implementation
There are two subpackages within the jsonformat renderer package. The differ
package compares the before and after values of the given plan and produces
Diff objects from the computed package.
This approach is aimed at ensuring the process by which the plan difference is
calculated is separated from the rendering itself. In this way it should be
possible to modify the rendering or add new renderer formats without being
concerned with the complex diff calculations.
The differ package
The differ package operates on Change objects. These are produced from
jsonplan.Change objects (which are produced by the tofu show command).
Each jsonplan.Change object represents a single resource within the overall
OpenTofu configuration.
The differ package will iterate through the Change objects and produce a
single Diff that represents a processed summary of the changes described by
the Change. You will see that the produced changes are nested so a change to a
list attribute will contain a slice of changes, this is discussed in the
"The computed package" section.
The Change object
The Change objects contain raw Golang representations of JSON objects (generic
interface{} fields). These are produced by parsing the json.RawMessage
objects within the provided changes.
The fields the differ cares about from the provided changes are:
Before: The value before the proposed change.
After: The value after the proposed change.
Unknown: If the value is being computed during the change.
BeforeSensitive: If the value was sensitive before the change.
AfterSensitive: If the value is sensitive after the change.
ReplacePaths: If the change is causing the overall resource to be replaced.
In addition, the changes define two additional meta fields that they set and
manipulate internally:
BeforeExplicit: If the value in Before is explicit or an implied result due to a change elsewhere.
AfterExplicit: If the value in After is explicit or an implied result due to a change elsewhere.
The actual concrete type of each of the generic fields is determined by the
overall schema. The changes are also recursive, this means as we iterate through
the Change we create relevant child values based on the schema for the given
resource.
For example, the initial change is always a block type which means the
Before and After values will actually be map[string]interface{} types
mapping each attribute and block to their relevant values. The
Unknown, BeforeSensitive, AfterSensitive values will all be either a
map[string]interface{} which maps each attribute or nested block to their
unknown and sensitive status, or it could simply be a boolean which generally
means the entire block and all children are sensitive or computed.
In total, a Change can represent the following types:
Attribute
map: Values will typically be map[string]interface{}.
list: Values will typically be []interface{}.
set: Values will typically be []interface{}.
object: Values will typically be map[string]interface{}.
tuple: Values will typically be []interface{}.
bool: Values will typically be a bool.
number: Values will typically be a float64.
string: Values will typically be a string.
Block: Values will typically be map[string]interface{}, but they can be
split between nested blocks and attributes.
Output
- Outputs are interesting as we don't have a schema for them, as such they
can be any JSON type.
- We also use the Output type to represent dynamic attributes, since in both
cases we work out the type based on the JSON representation instead of the
schema.
The ReplacePaths field is unique in that it's value doesn't actually change
based on the schema - it's always a slice of index slices. An index in this
context will either be an integer pointing to a child of a set or a list or a
string pointing to the child of a map, object or block. As we iterate through
the value we manipulate the outer slice to remove child slices where the index
doesn't match and propagate paths that do match onto the children.
Quick note on explicit vs implicit: In practice, it is only possible to get
implicit changes when you manipulate a collection. That is to say child values
of a modified collection will insert nil entries into the relevant before
or after fields of their child changes to represent their values being deleted
or created. It is also possible for users to explicitly put null values into
their collections, and this behaviour is different to deleting an item in the
collection. With the BeforeExplicit and AfterExplicit values we can tell the
difference between whether this value was removed from a collection or this
value was set to null in a collection.
Quick note on the go-cty Value and Type objects: The Before and After
fields are actually go-cty values, but we cannot convert them directly because
of the cloud backend redacted endpoint. The redacted endpoint turns sensitive
values into strings regardless of their types. Because of this, we cannot just
do a direct conversion using the ctyjson package. We would have to iterate
through the schema first, find the sensitive values and their mapped types,
update the types inside the schema to strings, and then go back and do the
overall conversion. This isn't including any of the more complicated parts
around what happens if something was sensitive before and isn't sensitive after
or vice versa. This would mean the type would need to change between the before
and after value. It is in fact just easier to iterate through the values as
generic JSON interfaces, and obfuscate the sensitive values as we never need to
print them anyway.
Iterating through changes
The differ package will recursively create child Change objects for the
complex objects.
There are two key subtypes of a Change: SliceChange and MapChange.
SliceChange values are used by list, set, and tuple attributes. MapChange
values are used by map and object attributes, and blocks. For what it is worth
outputs and dynamic types can end up using both, but they're kind of special as
the processing for dynamic types works out the type from the JSON struct and
then just passes it into the relevant real types for actual processing.
The two subtypes implement GetChild functions that retrieve a child change
for a relevant index (int for slice, string for map). These functions build
an entirely populated Change object, and the package will then recursively
compute the change for the child (and all other children). When a complex change
has all the children changes, it then passes that into the relevant complex
diff type.
The computed package
A computed Diff should contain all the relevant information it needs to render
itself.
The Diff itself contains the action (eg. Create, Delete, Update), and
whether this change is causing the overall resource to be replaced (read from
the ReplacePaths field discussed in the previous section). The actual content
of the diffs is passed directly into the internal renderer field. The internal
renderer is then an implementation that knows the actual content of the changes
and what they represent.
For example to instantiate a diff resulting from updating a list of
primitives:
listDiff := computed.NewDiff(renderers.List([]computed.Diff{
computed.NewDiff(renderers.Primitive(0.0, 0.0, cty.Number), plans.NoOp, false),
computed.NewDiff(renderers.Primitive(1.0, nil, cty.Number), plans.Delete, false),
computed.NewDiff(renderers.Primitive(nil, 4.0, cty.Number), plans.Create, false),
computed.NewDiff(renderers.Primitive(2.0, 2.0, cty.Number), plans.NoOp, false)
}, plans.Update, false))
The RenderHuman function
Currently, there is only one way to render a change, and it is implemented via
the RenderHuman function. In the future, there may be additional rendering
capabilities, but for now the RenderHuman function just passes the call
directly onto the internal renderer.
Rendering the above diff with: listDiff.RenderHuman(0, RenderOpts{}) would
produce:
[
0,
- 1 -> null,
+ 4,
2,
]
Note, the render function itself doesn't print out metadata about its own change
(eg. there's no ~ symbol in front of the opening bracket). The expectation is
that parent changes control how child changes are rendered, so are responsible
for deciding on their opening indentation, whether they have a key (as in maps,
objects, and blocks), or how the action symbol is displayed.
In the above example, the primitive renderer would print out only 1 -> null
while the surrounding list renderer is providing the indentation, the symbol and
the line ending commas.
Implementing new diff types
To implement a new diff type, you must implement the internal Renderer
functionality. To do this you create a new implementation of the
computed.DiffRenderer, make sure it accepts all the data you need, and
implement the RenderHuman function (and any other additional render functions
that may exist).
Some changes publish warnings that should be displayed alongside them.
If your new change has no warnings you can use the NoWarningsRenderer to avoid
implementing the additional Warnings function.
If/when new Renderer types are implemented, additional Render like functions
will be added. You should implement all of these with your new change type.
Implementing new renderer types for changes
As of January 2023, there is only a single type of renderer (the human-readable)
renderer. As such, the Diff structure provides a single RenderHuman
function.
To implement a new renderer:
- Add a new render function onto the internal
DiffRenderer interface.
- Add a new render function onto the
Diff struct that passes the call onto
the internal renderer.
- Implement the new function on all the existing internal interfaces.
Since each internal renderer contains all the information it needs to provide
change information about itself, your new Render function should pass in
anything it needs.
New types of Renderer
In the future, we may wish to add in different kinds of renderer, such as a
compact renderer, or an interactive renderer. To do this, you'll need to modify
the Renderer struct or create a new type of Renderer.
The logic around creating the Diff structures will be shared (ie. calling
into the differ package should be consistent across renderers). But when it
comes to rendering the changes, I'd expect the Diff structures to implement
additional functions that allow them to internally organise the data as required
and return a relevant object. For the existing human-readable renderer that is
simply a string, but for a future interactive renderer it might be a model from
an MVC pattern.