Load Modules from CMDBs

[roleyfoley]

Current Behaviour

With #1439 we introduced the ability to load scenarios that have been implemented in a provider. To use and develop scenarios you need to essentially create your own provider and include the scenarios as part of this provider.

Expected Behaviour

For solutions with highly repeated components you might want to develop a solution or product specific set of scenarios that are repeated across your product but might not be suitable for other products

Possible Solution

Include scenarios in our CMDB layout and load them as part of the boostrap process for process generation

Context

This would allow for users to develop their own scenarios as part of an isolated product

[RossMurr4y]

I would add to this a "nice to have" feature - probably not in the MVP though - of the following:

• Being able to specify in the solution as configuration a list of modules by URL
• The modules could then be downloaded and stored locally alongside their commit reference - similar to build.json structure
• The configuration should allow me to be able to "pin" to a given commit reference, or use the latest
• At generation time, any new/missing modules would be pulled into the solution and committed as a part of the solution

[roleyfoley]

Would we do that at the provider level or the module level? My thinking was to do it as part of #1447 at the plugin/provider level instead

[RossMurr4y]

Re-reading your initial description I can see that I've misunderstood - ...but might not be suitable for other products. So my suggestion isn't really related to your original intent here. I think what I've touched on is that the utility of the module is greater than any one use-case.

Here's how I see the breakdown:

• As a hamlet user who's responsible for a lot of infrastructure, I want to be able to design and use some repeatable patterns throughout my infrastructure so that I can maintain the definition and see the maintenance reflected everywhere its used. I see these patterns being only of use to me, so I don't want to publish them anywhere outside of my control.

• As a plugin provider developer, I want to be able to create modular products that I can chop and change as I choose. I'd also like to be able to make use of modules that were perhaps initially designed for a different provider.

• As a hamlet user, I would like to be able to browse a "marketplace" of sorts to see what pre-made modules are out there that suit my needs. If I feel I have a simple enough architecture pattern requirements it'd expect to be able to pull something down, add my Accounts CMDB and be off deploying my infrastructure. Whereas I could just copy/paste from a premade solution I've found, being able to pull down something that I know is maintained means that I can manage less. So long as the module is receiving updates I can leave the work to keeping up with the best practices to someone else.

• As a software developer who makes software designed to undertake work in the cloud (for the sake of thinking through use-cases, anyway), I'd like an easy way to be able to design and implement an architecture pattern that would allow users to get up and going with my product as fast as possible. Ideally they'd be able to find it on a common marketplace, and if this method proves particularly helpful perhaps I will even choose it as the primary method of deployment that I advertise to my users.

At the module level, all of these could be implemented. However given the experience/knowledge overhead required to implement them at the provider level, there are fewer people who will be able to make use of this functionality there.