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
