cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Weingärtner <rafaelweingart...@gmail.com>
Subject Re: Miami CCC '17 Roundtable/Hackathon Summary
Date Tue, 30 May 2017 14:15:22 GMT
Hahaha, yes I know ;)
And now you can see why I started that discussion to use a standard to
describe applications clusters, instead of an ad-hoc solution.

The idea is to kill two rabbits with a single shot (or at least one and a
half).

On Tue, May 30, 2017 at 2:28 AM, Daan Hoogland <daan.hoogland@shapeblue.com>
wrote:

> At the moment I am looking at CAMP, used by Apache Brooklyn, to see if it
> makes sense to embed a Brooklyn engine in ACS. There is an extension to
> Brooklyn for TOSCA for comparison but I’d like to keep it as simple as
> possible and hence use CAMP. (as you know Rafael ;)
>
> On 29/05/2017, 23:17, "Rafael Weingärtner" <rafaelweingartner@gmail.com>
> wrote:
>
>     On this idea of Rene to easily provide ways for vendors to integrate
>     solutions; if we had an endpoint that receives a blueprint for VM(s)
>     described in some language (let’s say TOSCA) we might be able to
> achieve
>     that without needing to add tons of code to ACS. Appliances could be
>     described in this language and would be easily introduced into ACS
>     (pluggable appliances?); then there is the matter of creating
> customization
>     endpoints for the deployed appliance, so administrators can configure
> it.
>     We also would need to improve further the internals of ACS to provide
>     better extension points for anyone that wants to extend/enhance its
> core
>     features.
>
>     I also agree with everything discussed so far that even if we
> modularize
>     the VR, we need to do so in a transparent way for the
>     operators/administrators that are already used to the ACS way of doing
>     cloud.
>
>     On Mon, May 29, 2017 at 8:46 AM, Rene Moser <mail@renemoser.net>
> wrote:
>
>     > Hi
>     >
>     > On 05/23/2017 02:16 PM, Simon Weller wrote:
>     >
>     > > We floated some ideas related to short term VR fixes in order to
> make it
>     > more modular, as well as API driven, rather than the currently SSH
> JSON
>     > injections.
>     >
>     > Speaking about endless possibilities... ;)
>     >
>     > I support the initiative (+1) to make the routing more API driven and
>     > modular, the issue I see with a "too hard backed" appliance is the
>     > integration into the existing environment.
>     >
>     > One big benefit of the VR is that we can relatively easy customize
> it.
>     >
>     > I had some thoughts about how to integrate a standardized "custom
>     > configuration" mechanism to the VR.
>     >
>     > I like the idea to have a "user data" or "cloud init" for the VR on
> the
>     > network offerings level. This would allow any virtual appliance
> "vendor"
>     > to implement a simple interface (e.g. static yaml/json data) which
>     > allows the "cloudstack admin" to customize the virtual appliance in
> the
>     > network offerings API.
>     >
>     > E.g. for our VR, the "cloud init" interface would allow
>     >
>     > * to install and configure custom monitoring solution
>     > * configure the automated update mechanism
>     > * add web hooks to trigger what so ever
>     > * install and run cfgmgmt like puppet/ansible-pull
>     > * etc.
>     >
>     > So for any virtual appliance the interfaces would be the same but the
>     > config option would differ based on features they provide.
>     >
>     > Regards
>     > René
>     >
>
>
>
>     --
>     Rafael Weingärtner
>
>
>
> daan.hoogland@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>


-- 
Rafael Weingärtner

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