Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of alex.heneveld@cloudsoftcorp.com
 designates 209.85.215.53 as permitted sender)
Message-ID: <50EC2E6A.5080105@CloudsoftCorp.com>
Date: Tue, 08 Jan 2013 14:34:18 +0000
From: Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS] PaaS Enablement: Composite Application Blueprints
 (#576)
References: <50E751DC.7000206@CloudsoftCorp.com>
 <2529883E7B666F4E8F21F85AADA43CA7010C8F171D3E@BANPMAILBOX01.citrite.net>
 <CAOvkMoaMaCju6=mETyGpRvS3oe7xtJ39a8zYfWbzXx7t=YQcdQ@mail.gmail.com>
In-Reply-To: 
 <CAOvkMoaMaCju6=mETyGpRvS3oe7xtJ39a8zYfWbzXx7t=YQcdQ@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------080909090603040104070606"

--------------080909090603040104070606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Thanks for all the comments and support so far!  Great to have so much 
interest and especially so many volunteers.

Some of the main points in my mind, on the discussion so far:

*"A new unit of deployment"* is a perfect description of this, Chris.  
And +1 to once it is deployed mapping it on to "projects" -- seems like 
a good fit to me, although I'm no projects expert.  Thoughts?

*The description format* is crucial to this feature's success, I think.  
For me priorities are to make it simple to use and simple to understand, 
and to align / be compatible with standards where feasible.  But there 
are multiple choices as people have noted.  The logical architecture to 
me would be a core description format which is an extensible standard, 
with some easy-to-use formats available on top of these.
*As a core native format*, what do people think of Oasis TOSCA's XML 
vocabulary [1] ?  I've worked with it for a while, and it has the right 
general concepts I think we'd need, done well, and in a way which won't 
bite us down the line.  (Alex Huang, in answer to your question, I 
strongly suspect that re-using cloudformation or vapp/OVF as _native_ 
will end up being too restrictive.)  It's not very user friendly, 
however, so we'd definitely want...
*    Easy-to-use description formats* layered on top of this:  AWS 
CloudFormation is an obvious desire; OVA/OVF/vApp could be useful; and 
personally I'd like to see a lightweight YAML dialect based on 
Cloudstack-specific concepts (to make it super-simple to create blueprints).
     Disclaimer:  I'm just suggesting this for discussion.  I'm not at 
all sure what is "right"; I'm just sure it's important to get it close 
to right!

*The API *portion I think is straightforward.  It's REST, you can list 
'em, upload new ones, delete, and get info (on templates).  Perhaps in 
time you could extend.  For deployed instances, it's just the Projects 
REST API.
     DMTF CIMI model & REST draft [2] (thanks for the pointer Chris) is 
a good guide to functionality/concepts but I think not as far as API 
goes?  Wouldn't people want the API to be consistent with the rest of 
cloudstack API?  (But a CIMI skin, e.g. deltaclouds, mapping on to the 
blueprints API in cloudstack, that I like.)

*The GUI* is something that hasn't been discussed much.  What should 
this look like?  A searchable library (like for VMs) seems the obvious 
choice, as a separate module in the CS GUI, populated by uploading 
description files as noted above?  All using the REST API of course.  
(And in time there might be "designer" features where you can 
build/extend blueprints in the GUI.)  Once deployed things they appear 
as projects, perhaps extending that GUI+API to support additional info 
for things which come from blueprints.  Is that what people were thinking?

*On the topic of in-guest automation,* +1 to calling this out as a 
separate _task_, but is it by itself a feature?  I see it as a code 
library -- which this blueprints feature obviously needs, and which 
should be modular, and which would be useful for other features (e.g. 
possibly having GUI hooks where a user can right click on a VM and 
invoke in-guest automation, assuming password hasn't changed).  But the 
use case of defining a VM with files installed and a command invoked 
would be handled by a simple blueprint.  So I think add such a use case, 
and make sure this library is modular, but not sure it should be a 
separate feature. (Unless there is a precedent for "developer features" ?)

*As for PaaS* total agreement here that PaaS-enablement is just a use 
case -- an important one -- but the feature itself is independent of 
PaaS and useful in non PaaS.

*For planning, more generally, *(and again answering Alex Huang's other 
question) once we have some support and consensus (which we're starting 
to get) I think we definitely need to phase in the features, and break 
those in to smaller tasks.  There is a lot here.  Ideally I'd like to 
identify some core where we could get something indicative pretty 
quickly (a couple months) then adjust this in response to feedback, and 
build upon it for additional features.  (This bit at least isn't 
controversial, is it?!)

Thanks folks and please keep it coming.

--A

[1] http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.html
[2] 
http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.0a.pdf


On 08/01/2013 07:50, Mohammad Nour El-Din wrote:
> Big +1
>
> I would also take the chance mentioning that I would like to help coding
> wise and planning also if/when possible
>
> Allow me to take this thread one step further and say that I can see at
> least an initial consensus if not a good enough one to start taking it into
> a one or more separate threads where we can discuss more planning and
> technical details
>
> Thoughts ?
>
> On Tue, Jan 8, 2013 at 7:25 AM, Koushik Das <koushik.das@citrix.com> wrote:
>
>> +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
>>
>


--------------080909090603040104070606--