Hi Sent from my Samsung Galaxy S3 Apologies for any typos On Jan 16, 2013 6:01 PM, "Shane Witbeck" <sh...@digitalsanctum.com> wrote: > > +1 for YAML. After all, YAML is a superset of JSON [1] which is the primary objective of the 1.2 spec. > > Here are my pros and cons: > > Pros: > - relational anchors and aliases (potential here for less verbosity through reuse) > - more readable > - comments > - projects which I respect, choose yaml over json for similar types of configuration [2], [3] > > Cons: > - more complex to parse, less mature libraries compared to json > > All this being said, I would advocate that more initial focus should be on the "model" and how it solves the problem of defining the "blueprint". Serialization format discussion should be secondary and around whatever best fits the model, not the other way around.
+1 on that > > > [1] http://yaml.org/spec/1.2/spec.html#id2759572 > [2] http://www.elasticsearch.org/guide/reference/setup/configuration.html > [3] https://github.com/cloudfoundry/bosh-release/blob/master/micro/aws.yml > > > -- > Shane Witbeck > > > On Thursday, January 10, 2013 at 1:20 PM, Kelcey Damage (BT) wrote: > > > +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 (http://www.backbonetechnology.com) > > ------------------------------------------------------------------------- > > kel...@backbonetechnology.com (mailto: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 (mailto: 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 >
