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
url).
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?
Aled
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]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/ApplicationCluster+service
[2] https://github.com/shapeblue/ccs
Daan Hoogland
Senior Software Developer
*s:* +31 61400 4545**| *d: *+44(0) 20 3603 0540
*e:* [email protected] |*w: *www.shapeblue.com |*t:* @shapeblue
*a:* 53 Chandos Place, Covent Garden, London WC2N 4HSUK
CloudStack Collab Miami 2017 <http://us.cloudstackcollab.org/>
------------------------------------------------------------------------
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
<http://shapeblue.com/iaas-cloud-design-and-build/> | CSForge – rapid
IaaS deployment framework <http://shapeblue.com/csforge/>
CloudStack Consulting <http://shapeblue.com/cloudstack-consultancy/> |
CloudStack Software Engineering
<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support
<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack
Bootcamp Training Courses <http://shapeblue.com/cloudstack-training/>
