cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Min Chen <>
Subject Re: [DISCUSS] PaaS Enablement: Composite Application Blueprints (#576)
Date Thu, 10 Jan 2013 17:31:17 GMT
Thanks a lot for your clarifications, Alex. Regarding language, personally
I am not in favor of YAML, although YAML gets rid of curly braces and
quotes, correct indentation required by YAML is also annoying to users.


On 1/9/13 4:39 PM, "Alex Heneveld" <> wrote:

>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
>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
>> tier, server, and DB, users can define different deployment models for
>> 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
>(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)
>> 2) Have you thought of creating Service offerings from your defined
>> blueprints? This may allow CloudStack to provide some SaaS
>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
>> 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
>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
>> 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.

View raw message