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