Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Date: Wed, 16 Jan 2013 12:00:28 -0500
From: Shane Witbeck <shane@digitalsanctum.com>
To: cloudstack-dev@incubator.apache.org
Cc: Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
Message-ID: <8BC36449D5CD4B30A18DECA7040DD17B@digitalsanctum.com>
In-Reply-To: <080901cdef5f$286d0f60$79472e20$@backbonetechnology.com>
References: <CD1198E3.4964%min.chen@citrix.com>
 <50EE0DA6.4030305@CloudsoftCorp.com>
 <080901cdef5f$286d0f60$79472e20$@backbonetechnology.com>
Subject: Re: [DISCUSS] PaaS Enablement: Composite Application Blueprints
 (#576)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="50f6dcac_2e22fbb7_552"

--50f6dcac_2e22fbb7_552
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

+1 for YAML. After all, YAML is a superset of JSON =5B1=5D which is the p=
rimary objective of the 1.2 spec.

Here are my pros and cons:

Pros:
- relational anchors and aliases (potential here for less verbosity throu=
gh reuse)
- more readable
- comments
- projects which I respect, choose yaml over json for similar types of co=
nfiguration =5B2=5D, =5B3=5D

Cons:
- more complex to parse, less mature libraries compared to json

All this being said, I would advocate that more initial focus should be o=
n the =22model=22 and how it solves the problem of defining the =22bluepr=
int=22. Serialization format discussion should be secondary and around wh=
atever best fits the model, not the other way around.


=5B1=5D http://yaml.org/spec/1.2/spec.html=23id2759572 =20
=5B2=5D http://www.elasticsearch.org/guide/reference/setup/configuration.=
html
=5B3=5D https://github.com/cloudfoundry/bosh-release/blob/master/micro/aw=
s.yml


-- =20
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 sim=
ply pass to a Python dictionary, however for interaction I am going to ba=
ck the YAML choice.
> =20
> KELCEY DAMAGE =20
> Infrastructure Systems Architect =20
> www.backbonetechnology.com (http://www.backbonetechnology.com) =20
> -----------------------------------------------------------------------=
-- =20
> kelcey=40backbonetechnology.com (mailto:kelcey=40backbonetechnology.com=
)
> =20
> 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
> =20
> =20
> > -----Original Message-----
> > =46rom: Alex Heneveld =5Bmailto:alex.heneveld=40cloudsoftcorp.com=5D
> > Sent: Wednesday, January 09, 2013 4:39 PM
> > To: cloudstack-dev=40incubator.apache.org (mailto:cloudstack-dev=40in=
cubator.apache.org)
> > Cc: Min Chen
> > Subject: Re: =5BDISCUSS=5D PaaS Enablement: Composite Application Blu=
eprints
> > (=23576)
> > =20
> > =20
> > Hi Min, Jie,
> > =20
> > Min, nice questions. I've given my answers in-line.
> > =20
> > Jie, my answers also respond to some of your points, re TOSCA and
> > YAML/JSON.
> > =20
> > =20
> > On 08/01/2013 17:50, Min Chen wrote:
> > > +1 on this feature to extend CloudStack from pure IaaS to PaaS or S=
aaS
> > > area. Some questions in my mind:
> > > =20
> > > 1) Does your proposed blueprint only contain functional component
> > > description or contain both functional and deployment aspects=3F =46=
or
> > > example, for a 3-tier app containing three functional components li=
ke
> > > web tier, server, and DB, users can define different deployment mod=
els
> > > for the same functional components, like small deployment (co-hosti=
ng
> > > all components on one VM), or medium or large deployment.
> > > =20
> > =20
> > Great use case. Introduces a =5Flot=5F of complexity:
> > =20
> > (1) allow parameters to be passed to the blueprint (e.g. =22size=22)
> > (2) separate the components that are to be created from the customiza=
tions
> > performed
> > (so you could define customizations for webserver, appserver, and dat=
a,
> > 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 =22webserver customization=22 lives as its own reusable modul=
e)
> > (4) allow conditional branching based on parameters
> > (e.g. if user selects =22size=3Dsmall=22 then run all customisations =
on single VM)
> > =20
> > I'd be inclined to DE=46ER them as features, until phase 2 or 3, but =
we should
> > consider how the description might support them as I'd like to see so=
me of
> > this functionality eventually.
> > =20
> > What do other people think=3F This is obvious functionality to want, =
what's the
> > right way to support it but without making the description language
> > complicated=3F
> > =20
> > (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), arbitr=
ary
> > nodes (2), and references to other definitions (3). It also has the c=
oncepts of
> > requirements / capabilities, relationships, policies, and plans -- so=
me of which
> > could be used to support (4)
> > eventually.)
> > =20
> > > 2) Have you thought of creating Service offerings from your defined=

> > > blueprints=3F This may allow CloudStack to provide some SaaS functi=
onalities.
> > > =20
> > =20
> > I like this idea, although it might break assumptions made elsewhere =
about
> > service offerings so we should look at it carefully.
> > =20
> > > 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 J=
SON
> > > format before in BMC Cloud LifeCycle product 2.0.
> > > =20
> > =20
> > Wow JSON seems popular so far. And yet YAML is more concise and
> > expressive. Designed to be easy for people to read and write configur=
ation
> > 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 pur=
pose to
> > me -- and my experience has been that it is easier to read and to wri=
te,
> > without the litter of curly braces and quotes.
> > =20
> > But I don't want to be a language bigot=21 I can go with JSON if that=
's what
> > people want. :)
> > =20
> > > 4) =46or a multi-tier application, blueprint should not only descri=
be
> > > different components, but also connections among those components,
> > > like open port, LB and =46W 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.
> > > =20
> > =20
> > 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 h=
ard-
> > coded patterns in there (e.g. for groups, load-balancers). But that o=
nly gets
> > you so far, and then you hit a wall (or spin up a different orchestra=
tor).
> > =20
> > Using requirements/capabilities and typed relationships gives a much =
more an
> > elegant solution. (Not necessarily TOSCA, but these concepts are well=

> > developed there=21)
> > =20
> > In any case let's make sure the use cases include interesting situati=
ons like
> > this, and we can compare approaches. This absolutely DOES need to be =
in
> > phase 1 I think.
> > =20
> > > 5) =46rom a normal user perspective, I would really love to see a G=
UI
> > > tool developed around this to allow user to visually create/edit a
> > > multi-tier app blueprint instead of using a TextEditor.
> > > =20
> > =20
> > Nice to hear. Me too. The description, API, and backend come first, w=
ith an
> > initial set of features, but I'd love to see the GUI in phase 2.
> > =20
> > > Thanks
> > > -min
> > > =20
> > =20
> > Keep it coming please.
> > =20
> > --Alex =20


--50f6dcac_2e22fbb7_552--