incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject Re: [DISCUSS] PaaS Enablement: Composite Application Blueprints (#576)
Date Mon, 07 Jan 2013 14:46:08 GMT
On Fri, Jan 4, 2013 at 5:04 PM, Alex Heneveld
<> wrote:
> 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.

Wonderful to see you bring this back up again Alex!  You were on my
list of folks to follow up with...  checking that one off the list
right now.

> 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

+1 to this, and I'd like to see if the AWS CloudFormation API could be
implemented as part of this (alongside the rest of our AWS API
capabilities).  Although, I'd also like to see if we can have a CS
specific implementation of the capability as the core interface
(again, similarly to how the EC2 API is really a wrapper on top of CS
native logic).

>     (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

+1 to this as a general concept, but I'd like to understand more about
what you mean by this.  Unlike item (a) above, which I can easily see
in my mind's eye, I'm not clear about how this would play with the
rest of the system.

> 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")

Let's make sure we are using UUIDs...  ;-)

> - 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

Adding LB rules would be helpful as well.

> * 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)

This portion is going to need some further discussion.  To date,
CloudStack hasn't gone into the guest OS itself.  I'm not saying that
we shouldn't know how to do it...  but we should strongly consider
leveraging tools designed for this (as you mention with the
puppet/chef/bash/juju/cartridges/brooklyn point).

> * 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?

After the discussion continues, I think that the next step will be to
begin to draft up the functional spec.  Since this is still early in
planning, the right parent page would be

Thanks again Alex...  Excited to see you (and I assume others soon)
taking this on!

> Many thanks,
> Alex
> [1]

View raw message