brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Macartney <geoff.macart...@cloudsoftcorp.com>
Subject Re: ApplicationClusters
Date Tue, 30 May 2017 13:24:38 GMT
You beat me to it Aled! :-)  was just writing my own reply.

Oh well, it's written now anyway, so here it is, for what it's worth:

hi Dan,

Good to chat to you on IRC this morning; I'll just add a few further
thoughts - I can't speak for the whole Apache Brooklyn community of course
but it seems to me that Brooklyn would be a very natural and good fit for
what you are trying to do.

Brooklyn could take care not only of the "Cluster life-cycle management"
outlined in your Functional Spec [1], but also the "Provisioning service
orchestrator" that you mention as being out of scope of the Application
Cluster service. That's what Brooklyn is designed to do - you model your
app in a textual blueprint; deploy it, in this case via Cloudstack; and
then manage it via predefined or custom policies (to take care of the "Life
cycle operations" mentioned in the FS.) Apache Cloudstack and Brooklyn will
work very nicely together.

Having thought a bit more about how to achieve that though, I think I want
to step back from what I said on IRC about interating with Brooklyn via
Java.  From an architectural viewpoint I think you want to keep them as
separate components and have Cloudstack talk to Brooklyn though the
Brooklyn REST API. This gives you separation of concerns, enforces a clear
API between components (Brooklyn's REST API defines very precisely what
Brooklyn does), keeps open the potential of scaling the components
independently, provides better fault tolerance and so on. Not to mention it
avoids all the hassles you might have gluing two large Java implementations
together, with possible difficulties due to differences in transitive
dependency versions and so on.   I think the point about enforcing a clear
API between the two is particularly important for successful interworking.

>From a USER perspective your users don't necessarily have to know about
Brooklyn, if it can be arranged for a Cloudstack installation to include
enough Brooklyn to run at least the REST API. I'm imagining the Cloudstack
installation including Brooklyn as a subcomponent here, and kicking a
Brooklyn process off during its own initialization.  The Cloudstack
instance could then act as a front end, taking care of the interactions
with the Brooklyn REST API for each user operation, and/or simply proxying
some requests to Brooklyn if no specific processing was required on the
request or response. Keeping them separate, however, leaves open the
possibility that users who *are* aware of Brooklyn could explicitly run
their own instance, which Cloudstack would work seamlessly with, just as if
it had installed it itself. It would just be a REST endpoint.

These are just my thoughts, I would be keen to hear what others in the
Apache Brooklyn community, as well as you in Cloudstack, think. I do think
the two would complement each other perfectly though, and in particular it
would be really nice that they are two Apache projects that could be used
naturally together to run a cloud.

If you like I could expand a bit on the correspondence, as I see it,
between the requirements in your FS and the things that Brooklyn already
does?

regards,
Geoff

[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/ApplicationCluster+service

On Tue, 30 May 2017 at 13:55 Aled Sage <aled.sage@gmail.com> wrote:

> 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 <+44%2020%203603%200540>
> > *e:* daan.hoogland@shapeblue.com |*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/>
> >
>
>

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