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
