Sunstone Views 4.0

Using the new OpenNebula Sunstone Views you will be able to provide a simplified UI aimed at end-users of an OpenNebula cloud. The OpenNebula Sunstone Views are fully customizable, so you can easily enable or disable specific information tabs or action buttons. You can define multiple cloud views for different user groups. Each view defines a set of UI components so each user just access and view the relevant parts of the cloud for her role.

OpenNebula provides a default user and admin view that implements two common views. By default, the admin view is only available to the oneadmin group. New users will be included in the users group and will use the deafault user view.

inlinetoc

Requirements

OpenNebula Sunstone Views does not require any additional service to run. You may want to review the Sunstone configuration to deploy advanced setups, to scale the access to the web interface or to use SSL security.

Usage

After logging into Sunstone, the view defined in /etc/one/sunstone-view for the user/group will be loaded automatically.

If more than one view are available for this user, she can easily change between them in the settings window, along with other settings (e.g. language).

views_settings.jpg views_conf.jpg

Advanced Configuration

There are three basic areas that can be tuned to adapt the default behavior to your provisioning needs:

  • Define views, the set of UI components that will be enabled.
  • Define the users and groups that may access to each view.
  • Brand your OpenNebula Sunstone portal.

Defining a new OpenNebula Sunstone View

View definitions are placed in the /etc/one/sunstone-views directory. Each view is defined by a configuration file, in the form:

   <view_name>.yaml

The name of the view is the the filename without the yaml extension. The default views are defined by the user.yaml and admin.yaml files, as shown below: <xterm> etc/ …

`– sunstone-views.yaml … </xterm>

The content of a view file specifies the tabs available in the view (note: tab is on of the main sections of the UI, those in the left-side menu). Each tab can be enabled or disabled by updating the enabled_tabs: attribute. For example to disable the Clusters tab, just comment the clusters-tab section: <xterm> enabled_tabs:

  1. dashboard-tab
  2. system-tab
  3. users-tab
  4. groups-tab
  5. acls-tab
  6. vresources-tab
  7. vms-tab
  8. templates-tab
  9. images-tab
  10. files-tab
  11. infra-tab

#- clusters-tab

  1. hosts-tab
  2. datastores-tab
  3. vnets-tab
  4. marketplace-tab

</xterm>

Each tab, can be tuned by selecting:

  • The bottom tabs available (panel_tabs: attribute) in the tab, these are the tabs activated when an object is selected (e.g. the information, or capacity tabs in the Virtual Machines tab).
  • The columns shown in the main information table (table_columns: attribute).
  • The action buttons available to the view (actions: attribute).

The attributes in each of the above sections should be self-explanatory. As an example, the following section, defines a simplified datastore tab, without the info panel_tab and no action buttons:

<xterm>

  datastores-tab:
      panel_tabs:
          datastore_info_tab: false
          datastore_image_tab: true
      table_columns:
          - 0         # Checkbox
          - 1         # ID
          - 2         # Owner
          - 3         # Group
          - 4         # Name
          - 5         # Cluster
          #- 6         # Basepath
          #- 7         # TM
          #- 8         # DS
          #- 9         # Type
      actions:
          Datastore.refresh: true
          Datastore.create_dialog: false
          Datastore.addtocluster: false
          Datastore.chown: false
          Datastore.chgrp: false
          Datastore.chmod: false
          Datastore.delete: false

</xterm>

:!: The easiest way to create a custom view is to copy the admin.yaml file to the new view then harden it as needed.

Configuring access to the Views

Once you have defined and customized the UI views for the different roles, you need to define which user groups or users may access to each view. This information is defined in the /etc/one/sunstone-views.yaml.

The views can be defined for:

  • Each user (users: section), list each user and the set of views available for her.
  • Each group (groups: section), list the set of views for the group.
  • The default view, if a user is not listed in the users: section, nor its group in the groups: section, the default views will be used.

For example the following enables the user (user.yaml) and admin (admin.yaml) for user helen and group oneadmin. The default views are just the user view: <xterm> users:

  helen:
      - admin
      - user

groups:

  oneadmin:
      - admin
      - user

default:

  1. user

</xterm>

A different endpoint for each view

OpenNebula Sunstone views can be adapted to deploy a different endpoint for each kind of user. For example if you want an endpoint for the admins and a different one for the cloud users. You will just have to deploy a new sunstone server (TODO deploy in a different machine link) and set a default view for each sunstone instance:

<xterm>

# Admin sunstone
cat /etc/one/sunstone-server.conf
  ...
  :host: admin.sunstone.com
  ...
cat /etc/one/sunstone-views.yaml
  users:
  groups:
  default:
      - admin

</xterm>

<xterm>

# Users sunstone
cat /etc/one/sunstone-server.conf
  ...
  :host: user.sunstone.com
  ...
cat /etc/one/sunstone-views.yaml
  users:
  groups:
  default:
      - user

</xterm>

Branding the Sunstone Portal

You can easily add you logos to the login and main screens by updating the logo: attribute as follows:

  • The login screen is defined in the /etc/one/sunstone-views.yaml.
  • The logo of the main UI screen is defined for each view in the view file.