cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@shapeblue.com>
Subject Re: Miami CCC '17 Roundtable/Hackathon Summary
Date Tue, 30 May 2017 06:28:56 GMT
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
  
 

Mime
View raw message