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