+1 for YAML, I find JSON good for when I never look at the data and simply pass to a Python dictionary, however for interaction I am going to back the YAML choice.
KELCEY DAMAGE Infrastructure Systems Architect www.backbonetechnology.com ------------------------------------------------------------------------- kel...@backbonetechnology.com address: 55 East 7th Ave, Vancouver, BC, V5T 1M4 tel: +1 604 713 8560 ext:114 fax: +1 604 605 0964 skype: kelcey.damage >-----Original Message----- >From: Alex Heneveld [mailto:alex.henev...@cloudsoftcorp.com] >Sent: Wednesday, January 09, 2013 4:39 PM >To: cloudstack-dev@incubator.apache.org >Cc: Min Chen >Subject: Re: [DISCUSS] PaaS Enablement: Composite Application Blueprints >(#576) > > >Hi Min, Jie, > >Min, nice questions. I've given my answers in-line. > >Jie, my answers also respond to some of your points, re TOSCA and >YAML/JSON. > > >On 08/01/2013 17:50, Min Chen wrote: >> +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. >Great use case. Introduces a _lot_ of complexity: > >(1) allow parameters to be passed to the blueprint (e.g. "size") >(2) separate the components that are to be created from the customizations >performed > (so you could define customizations for webserver, appserver, and > data, >then either > apply the customizations either to a single VM (small), distinct VM's >(medium), > or distinct VM groups (large)) >(3) allow blueprints to refer to other blueprints > (so the "webserver customization" lives as its own reusable module) >(4) allow conditional branching based on parameters > (e.g. if user selects "size=small" then run all customisations on > single VM) > >I'd be inclined to DEFER them as features, until phase 2 or 3, but we should >consider how the description might support them as I'd like to see some of >this functionality eventually. > >What do other people think? This is obvious functionality to want, what's the >right way to support it but without making the description language >complicated? > >(BTW one of the reasons I think TOSCA could be a good choice is that it has >considered many of these. You can define properties (1 above), arbitrary >nodes (2), and references to other definitions (3). It also has the concepts >of >requirements / capabilities, relationships, policies, and plans -- some of >which >could be used to support (4) >eventually.) > >> 2) Have you thought of creating Service offerings from your defined >> blueprints? This may allow CloudStack to provide some SaaS functionalities. >I like this idea, although it might break assumptions made elsewhere about >service offerings so we should look at it carefully. > >> 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. >Wow JSON seems popular so far. And yet YAML is more concise and >expressive. Designed to be easy for people to read and write configuration >just like this. Whereas JSON is designed for serializing objects, in a way >that >isn't too hard for people. YAML seems the right language for this purpose to >me -- and my experience has been that it is easier to read and to write, >without the litter of curly braces and quotes. > >But I don't want to be a language bigot! I can go with JSON if that's what >people want. :) > >> 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. >Yeah, this is where it gets interesting. A common trick I've seen is to use >hostnames for a lot of the connection configuration, and have a few hard- >coded patterns in there (e.g. for groups, load-balancers). But that only gets >you so far, and then you hit a wall (or spin up a different orchestrator). > >Using requirements/capabilities and typed relationships gives a much more an >elegant solution. (Not necessarily TOSCA, but these concepts are well >developed there!) > >In any case let's make sure the use cases include interesting situations like >this, and we can compare approaches. This absolutely DOES need to be in >phase 1 I think. > >> 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. >Nice to hear. Me too. The description, API, and backend come first, with an >initial set of features, but I'd love to see the GUI in phase 2. > >> Thanks >> -min >Keep it coming please. > >--Alex
