+1 on the feature and comments below. > *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).
I like the CloudFormation JSON format, which is readable. I agree that it is difficult to take it exactly because the entities in AWS is different from CloudStack. We can use CloudFormation as a reference to create something native for CloudStack, and align as much as possible. In addition, we can implement import/export utilities for CloudFormation and OVF in the future. As for TOSCA, there are quite a few PaaS vendors participating. The focus seems to be on software package deployment rather than creating multi-VM application deployment on IaaS (although the model is flexible enough to support both). It is in early stage. I am not sure if we should use this standard as the core native format for CloudStack. But I don't have much experience with TOSCA. So love to hear others' opinion. Jie > -----Original Message----- > From: Min Chen [mailto:min.c...@citrix.com] > Sent: Tuesday, January 08, 2013 9:51 AM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [DISCUSS] PaaS Enablement: Composite Application Blueprints > (#576) > > +1 on this feature to extend CloudStack from pure IaaS to PaaS or SaaS > area. Some questions in my mind: > > 1) Does your proposed blueprint only contain functional component > description or contain both functional and deployment aspects? For > example, for a 3-tier app containing three functional components like web > tier, server, and DB, users can define different deployment models for the > same functional components, like small deployment (co-hosting all > components on one VM), or medium or large deployment. > 2) Have you thought of creating Service offerings from your defined > blueprints? This may allow CloudStack to provide some SaaS functionalities. > 3) As for blueprint description language, easy-to-read and easy-to-edit by > human being should be necessary if we don't provide any visual GUI tools to > create/edit a blueprint. I have seen some JSON format before in BMC Cloud > LifeCycle product 2.0. > 4) For a multi-tier application, blueprint should not only describe different > components, but also connections among those components, like open port, > LB and FW rules among them. I assume that your blueprint is also taking that > into consideration, and your backend orchestration layer can provide enough > flexibility to provision any such app, seems not an easy task to me since I am > new to CS. > 5) From a normal user perspective, I would really love to see a GUI tool > developed around this to allow user to visually create/edit a multi-tier app > blueprint instead of using a TextEditor. > > Thanks > -min > > On 1/8/13 6:34 AM, "Alex Heneveld" <alex.henev...@cloudsoftcorp.com> > wrote: > > > > >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 > >>> > >> > >
