brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <>
Subject Re: ApplicationClusters
Date Tue, 30 May 2017 12:54:01 GMT
Hi Daan,

Sounds interesting! Brooklyn seems like a good fit for what you're 
looking for.

Within Brooklyn, there's a separation of the application definition and 
the location to which it is to be deployed - apps can be written to be 
location-agnostic. From your perspective, the good thing about that is 
someone can write an app without saying about the specific location, and 
then the location is wired in behind the scenes at deploy time (e.g. 
based on the given user's identity, and the implicit CloudStack endpoint 

Brooklyn also includes an application catalog. Users can choose apps 
from the catalog, can compose new apps using the catalog items as 
building blocks, and can add new blueprints to the catalog.

A few questions/comments:

Are you planning to extend the existing CloudStack API to support app 
provisioning (and the subsequent lifecycle of the app)? What about 
catalog management?

Could the new API calls take something like the Brooklyn YAML format for 
the app definitions, and for catalog items?

What is your reasoning on pros/cons of embedding Brooklyn versus running 
it as a stand-alone process (which could be automatically deployed as 
part of the CloudStack installation)? If it was a stand-alone app, one 
would interact with it via the REST api.

It's also worth mentioning OSGi. Brooklyn currently can be run as a 
vanilla Java process, or in Karaf. We're moving towards making more and 
more use of Karaf (e.g. it helps with versioning of catalog items, where 
those items include Java code or resources such as bash scripts uploaded 
to the Brooklyn server).

Does the place you embed Brooklyn run as an OSGi container? If not, then 
would that mean you'd want to stick with the non-karaf way of running 
the Brooklyn engine long-term?


On 24/05/2017 14:06, Daan Hoogland wrote:
> Hello,
> I am an Apache CloudStack developer and PMC member. At the last 
> apachecon I have been looking for feedback on a functional 
> specification for distributed applications [1]. So far, we have not 
> gotten any feedback from outside the project but from within we have 
> been searching our way around and have gotten to look at Brooklyn. 
> Hope you guys`n’dolls have some patients with me.
> What the CloudStack project aims to be is an integrated turnkey 
> solution for entry level cloud deployments. That means we don’t want 
> to burden users with extra install responsibilities as much as we can. 
> Looking at clustered environments we don’t want people to have to 
> install aria, Brooklyn or TerraForm to be able to orchestrate groups 
> of related VMs or containers. On the other hand, we do not want to 
> re-invent the wheel as we kind of did in the Functional Specification 
> from the link above [1].
> I know that Brooklyn supports CloudStack through a plugin but I am 
> looking for a way to integrate the engine, that Brooklyn provides, 
> into CloudStack so that writers of specific application plugins like 
> ccs, a K8Cluster plugin [2], can write their environment description 
> in a rather generic way and call the underlying CloudStack API to have 
> the ‘applicationscape’ automagically created.
> Do you people have any advice here?
> [1] 
> [2]
> Daan Hoogland
> Senior Software Developer
> *s:* +31 61400 4545**| *d: *+44(0) 20 3603 0540
> *e:* |*w: * |*t:*  @shapeblue
> *a:* 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> CloudStack Collab Miami 2017 <>
> ------------------------------------------------------------------------
> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue 
> Services India LLP is a company incorporated in India and is operated 
> under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda 
> is a company incorporated in Brasil and is operated under license from 
> Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The 
> Republic of South Africa and is traded under license from Shape Blue 
> Ltd. ShapeBlue is a registered trademark.This email and any 
> attachments to it may be confidential and are intended solely for the 
> use of the individual to whom it is addressed. Any views or opinions 
> expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not 
> the intended recipient of this email, you must neither take any action 
> based upon its contents, nor copy or show it to anyone. Please contact 
> the sender if you believe you have received this email in error.
> Find out more about ShapeBlue and our range of CloudStack related 
> services:
> IaaS Cloud Design & Build 
> <> | CSForge – rapid 
> IaaS deployment framework <>
> CloudStack Consulting <> | 
> CloudStack Software Engineering 
> <>
> CloudStack Infrastructure Support 
> <> | CloudStack 
> Bootcamp Training Courses <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message