Hi, @alex-frankel and @satyavel , thanks for clarifying. I am also wondering any plans to make module as more of unit of work (deployment) to maintain their own "state" supporting independent life cycle, and have its own cadence, etc. per our discussion last week. Another aspect of module I am interested, how module can be consumed, shared, etc. Is there any defined roadmap for composition from both type composition and deployment composition perspective?
The modules are going to be represented as a nested inline deployments in the ARM JSON, so you would be able to do some of the redeployment scenarios you showed us by simply retrying the specific deployment. Since we are turning them into the deployments, I think the foundation is there to do the rest.
It seems that dependsOn is automatically generated when referencing the outputs of the module from other modules. Therefore, I think there is a not need for an additional dependency definition mechanism.
In some cases, we are not able to figure out dependencies between modules. To deal with that, users need to be able to set the dependencies however they need. This will be accomplished via explicit dependsOn just like with resources.