cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kelcey Damage \(BT\)" <>
Subject RE: [DISCUSS] PaaS Enablement: Composite Application Blueprints (#576)
Date Mon, 07 Jan 2013 20:48:44 GMT
Right off the bat, I like what's being proposed here. Being able to 1-shot
provision application infrastructures is a great feature. And to store these
pocket infrastructures as blue-prints in the template system I think makes
the most sense.

As for guest automation, I too would like to see CloudStack provide at least
simple tools (login, service start/stop, upload/download file, walk
directory tree).

Great proposal, let's hope it generates a strong discussion.


>-----Original Message-----
>From: Chris Sears []
>Sent: Monday, January 07, 2013 12:32 PM
>Subject: Re: [DISCUSS] PaaS Enablement: Composite Application Blueprints
>This sounds like there a two major features wrapped up here that deserve to
>be broken out and discussed individually.
>1. A new unit of deployment similar to a VMware vApp or AWS
>CloudFormation template. This unit would have an abstract representation
>(blueprint/template) and a deployed instance representation (something like
>a project) that contains the related VMs, networks and other runtime
>resources. The DMTF CIMI API has some related concepts called System
>Templates and Systems that might be worth reviewing for compatibility
>considerations. Also, the OVF standard has some relevant material that
>allow us to import/export these units as OVF/OVA files.
>2. Extended in-guest automation. Running commands in the guest. Copying
>files into and out of the guest file system. Something generic enough that
>folks could bootstrap a higher-level config management tool like those you
>mention or do basic guest-level automation (if they didn't need a more
>complex tool). This might be implemented on top of SSH, WinRM or VMware
>I certainly see how they are critical to PaaS enablement, it might be less
>confusing to address them independently of the PaaS issue.
>Looking forward to helping on these.
> - Chris
>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.
>> 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]

View raw message