+1 to the feature.
This will definitely help in doing initial application prototype and testing on a test cloud
and once everything is tuned up properly the application can be exported as a package and
imported to a production cloud and with minimal configuration changes should be up and running.
-Koushik
> -----Original Message-----
> From: Alex Heneveld [mailto:alex.heneveld@cloudsoftcorp.com]
> Sent: Saturday, January 05, 2013 3:34 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: [DISCUSS] PaaS Enablement: Composite Application Blueprints
> (#576)
>
>
> Hi All,
>
> At the CCC, and in jira [1] late last year, we started discussing this feature
> request, but going foward we'd like to get broader feedback. A couple folks
> have suggested we bring it back to the mailing list to get this.
>
> In brief, we're responding to a desire for high-level composite blueprints on
> top of Cloudstack. For instance:
>
> (a) An app team wants to have a single entity in Cloudstack which
> represents their application,
> consisting of a load-balancer, a scalable appserver tier, and a SQL
> database
>
> (b) A middleware team wants to have a mechanism for describing a PaaS
> which they can
> deploy, manage (e.g. scale out, back), track costs, and destroy as a unit
> in Cloudstack
>
> These get mapped on to Cloudstack components (IaaS and services), but
> what distinguishes them from Projects is that they are reusable portable
> definitions. This is similar to what VMware have in vApp and AWS in
> CloudFormation; but there is (so far) a preference to base these around
> CloudStack concepts and have them accessible in the GUI.
>
> Cloudsoft (me and others here) want to work on this, together with like-
> minded folks.
>
> Here are some feature ideas for starters:
>
> * IaaS mapping
> - ability to refer to specific templates and offerings (eg id="1234")
> - ability to refer to portable descriptions of templates and offerings (eg
> os("ubuntu"), userdata("myappsrv"), minram("2gb"))
> - ability to define subnets, DNS, public IP and firewall rules
>
> * Wiring
> - ability to write files to VM's with permissions, mode, etc
> - ability to embed references to other blueprint entities (ie other VM
> IP's/hostnames) in such files
> - ability to execute commands on VM's, with order constraints
> - ability to use puppet/chef/bash/juju/cartridges/brooklyn (e.g. via the
> above capabilities)
>
> * Management
> - ability to access blueprints and deployments via REST and via GUI
> - ability to define clusters and groups of entities (which could be scaled)
> - ability to deploy policies (eg elasticity, HA/DR logic) to various management
> systems
>
> What would you like to see? Would you be able to help?
>
> Many thanks,
> Alex
>
> [1] https://issues.apache.org/jira/browse/CLOUDSTACK-576
|