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....@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.henev...@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
