cloudsoft.io

Known Limitations and Roadmap

We at Cloudsoft use Visual Composer for our own work managing customers’ estates: blueprints are the software engineering answer to infrastructure, with modularity, repeatability, testability. (If you want to know more about what Cloudsoft does, click here.)

Because of this, Visual Composer has grown up around the use cases and patterns we use. And we’ve no doubt missed good patterns that you and other users would like to see. This page summarizes some of the things we are working and on thinking about, and some of the known bugs in the software. It isn’t static, and it doesn’t happen in a vacuum, so please get in touch with your wishlist items:

Big Features on the Roadmap

  • Bespoke validation: As an AWS system administrator with responsibility for compliance, I want to be able to define validation rules for my organization that are enforced at design-time.

  • Auto-selection strategies: As an AWS systems administrator, I want the Composer to understand the strategies and conventions we use for selecting things like AMIs and subnets. It’s helpful that Composer shows me the values to select one, but this still needs to be changed manually when e.g. a new AMI is released, or we go to a new region. Things like the imageNameRegex are useful but they don’t go far enough, for instance because we want to pick the newest one or highest version value or we use tags instead of image names. Let us know the strategies you want to see.

  • Complex types editor: As an AWS CFN author, I want the Composer to do more for me when I need to set complex types. It’s good that the tool allows me to enter raw JSON for the types, but I’d like it to prompt me for the fields I need and give me context assistance for them, like it does for top-level properties on resources.

  • CFN Parameters and Outputs: As an AWS CFN author, I want the Composer to do more for me when I need to set inputs and outputs for templates. Currently it does let me include this, but I have to go to the Composer YAML editor and write it myself with no context assistance, inside a extraCloudFormationYaml config key (as described here).

  • Team support: As an AWS CFN author working in a larger team, I want the Composer to let me share my blueprints and load those made by other people. Currently I have to do this out-of-band, by e.g. switching to the YAML view and copy-pasting to GitHub, or using the CLI to do conversion. It would be nice to do all this graphically inside Composer. (If this is of interest, please let us know how you’d like to collaborate.)

Known Limitations and Bugs

  • Wrong config shown for library blueprints: Currently if you add a blueprint to the local Library Catalog and reference this in another blueprint, the Composer displays the config from the first child but none of its values. This means a user seems too much and has to re-enter values. The tool should either know the values set in the referenced blueprint or treat that configuration as internal and not show it; really it should only show parameters exported by that library item.

  • Limited simplified entities: There are a couple dozen entities that are used a lot. The Composer should show these when the “Simplified” button is enabled. We completely agree. We wanted to get a v1 out as early as possible but this is coming as soon as we can.