Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: "Kelcey Damage \(BT\)" <kelcey@backbonetechnology.com>
To: <cloudstack-dev@incubator.apache.org>
Cc: "'Min Chen'" <min.chen@citrix.com>
References: <CD1198E3.4964%min.chen@citrix.com>
 <50EE0DA6.4030305@CloudsoftCorp.com>
In-Reply-To: <50EE0DA6.4030305@CloudsoftCorp.com>
Subject: RE: [DISCUSS] PaaS Enablement: Composite Application Blueprints
 (#576)
Date: Thu, 10 Jan 2013 10:20:24 -0800
Message-ID: <080901cdef5f$286d0f60$79472e20$@backbonetechnology.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQECOILpaIGFN3ytMaP7zZEhCrOBRgIcKF0LmclrdRA=
Content-Language: en-us

+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=20
Infrastructure Systems Architect=20
www.backbonetechnology.com=20
-------------------------------------------------------------------------=
=20
kelcey@backbonetechnology.com

address: 55 East 7th Ave, Vancouver, BC, V5T 1M4
tel: +1 604 713 8560 ext:114=E2=80=83=E2=80=83 =20
fax: +1 604 605 0964=20
skype: kelcey.damage=20
=20


>-----Original Message-----
>From: Alex Heneveld [mailto:alex.heneveld@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=3Dsmall" 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