Sunstone Operations Center Server Plugin Guide 3.8
OpenNebula Sunstone server plugins consist a set files defining custom routes. Custom routes will have priority over default routes and allow administrators to integrate their own custom controllers in the Sunstone Server.
Sunstone server plugins complement Sunstone client-side plugins and allow to fully customize the behaviour of Sunstone.
It is very easy to enable custom plugins:
/etc/one/sunstone-server.confto indicate which files should be loaded, as shown in the following example:
# This will load ''custom.rb'' and ''other.rb'' plugin files. :routes: - custom - other
Sunstone server is a Sinatra application. A server plugin is simply a file containing one or several custom routes, as defined in sinatra applications.
The following example defines 4 custom routes:
get '/myplugin/myresource/:id' do resource_id = params[:id] # code... end post '/myplugin/myresource' do # code end put '/myplugin/myresource/:id' do # code end del '/myplugin/myresource/:id' do # code end
Custom routes take preference over Sunstone server routes. In order to easy debugging and ensure that plugins are not interfering with each others, we recommend however to place the routes in a custom namespace (
myplugin in the example).
From the plugin code routes, there is access to all the variables, helpers etc which are defined in the main sunstone application code. For example:
opennebula_client = settings.cloud_auth.client(session[:user]) sunstone_config = settings.config logger = settings.logger vm3_log = @SunstoneServer.get_vm_log(3)