deploymentScripts and module parameters and outputs?

[bmoore-msft]

When a module contains a deploymentScript should we expose properties of the deploymentScript resource (cli version, cleanup, retention) or optimize the module contract for the purpose of the workload? IOW, standardize the way modules leverage deploymentScripts and abstract that from the UX.

Exposing the deploymentScript properties creates unnecessary surface area (for failure) and adds to the complexity of the module... also makes it more of a breaking change should the script be replace some day by extensibility or a proper RP. Exposes the implementation, etc.

The flip side is that hardcoding something like CLI version will eventually break the module when an image is retired. Note this will break users regardless but hardcoding means the fix must come in the module itself - rather than user code. We could be proactive on these and ensure that we update before an image is retired.

Same is true for outputs - should we output things that are specific to the deploymentScript resource or only those things that are relevant to the purpose of the module?

[ChrisSidebotham]

Dear @bmoore-msft , Azure Verified Modules (AVM) will become the single Microsoft standard for Bicep modules. Transitioning to AVM, requests for new features or bug fixes will need to be submitted against the appropriate AVM module via AVM Module Issues.

For bugs or new features with existing modules in the /modules directory of this repository, we encourage you to first try the AVM equivalent module if available and if the module is lacking any features, you can file an AVM Module Issue. If the module is not available yet, you can file a new AVM Module Proposal.

See this informational notice for more details on the upcoming changes.

Thank you for your understanding!