Using the decompile option on a Blueprint json currently generates a single blueprint.py file along with separate directories for package install scripts and environments specs. The blueprint.py file is easy to understand after investing a bit of effort to understand Calm concepts.
However, editing the blueprint can become really difficult as it grows in complexity(such as addition of multiple profiles).
In case of a BP DSL file with multiple profiles and substrates, quickly identifying which profile a substrate belongs to can be really difficult(unless the substrate/provider name has a clear indication on the profile it belong to). It becomes even more difficult if there are multiple providers of the same type in the BP(say two Nutanix profiles). This is the same for other objects within profiles.
It would be great if we can split the decompiled DSL file into multiple files with a directory structure that would help users to:
Identify and understand calm abstractions easily
Edit a decompiled BP without too much effort
We can start with a structure similar to the one in the screenshot to split out profiles and services.
the common directory will contain any shared components to avoid duplication under profiles
I don’t have any better ideas on where to put the services directory for now
Using the decompile option on a Blueprint json currently generates a single
blueprint.py
file along with separate directories for package install scripts and environments specs. Theblueprint.py
file is easy to understand after investing a bit of effort to understand Calm concepts.However, editing the blueprint can become really difficult as it grows in complexity(such as addition of multiple profiles).
In case of a BP DSL file with multiple profiles and substrates, quickly identifying which profile a substrate belongs to can be really difficult(unless the substrate/provider name has a clear indication on the profile it belong to). It becomes even more difficult if there are multiple providers of the same type in the BP(say two Nutanix profiles). This is the same for other objects within profiles.
It would be great if we can split the decompiled DSL file into multiple files with a directory structure that would help users to:
We can start with a structure similar to the one in the screenshot to split out profiles and services.