A module is a jsonnet library that, when evaluated, yields an object conforming to the following subset of attributes of an ARM template:
{
resources: [
{ <resource definition> }
],
outputs: {
...: {
...
}
...
}
}
(In fact, an existing ARM template intended for inline use is a valid Module per this definition)
A module can be parameterized. Argument values are passed to the module by injecting a 'parameters' environment variable into the execution environment (equivaluent of passing a ext-str parameters=... to the jsonnet cli)
In addition to the core definition of a module, there are several conventions that, when followed, provide surrounding tooling with additional information/capabilities.
A module may declare parameters that it supports by providing a parmameterMetadata attribute. The parameterMetadata attribute includes the name, type and default value for parameters. TODO: additional functionality can be added to parameterMetadata, including imperative validation, descriptions, enum values etc.)
Example:
{
parameterMetadata:: {
stringValue: {
type: 'string'
},
optionalIntegerValue: {
type: 'number',
defaultValue: 7
}
}
}
A caller may inspect what arguments a module provides by examining the parameterMetadata field of the module. The parameterMetadata can also be used by the module (or caller) to validate the provided parameters.
TODO: if we rename parameterMetadata to parameters, and make sure we follow the same schema as an ARM template's parameters section, we have an ever stronger correlation between ARM templates and Modules. This way, we'd also make it a formal part of a module definition rather than a convention
In many cases, a module logically defines a root (anchor) resource with a set of dependent resources. A module may chose to expose this id to other modules by providing a top level id attribute.
A module author may take advantage of a core module definition that provides validation of parameters based on parameterMetadata.