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
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"
> 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
> 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.hoogl...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
>
>
>
--
Rafael Weingärtner
