Sahara Dashboard Configuration Guide

After installing the Sahara dashboard, there are a few extra configurations that can be made.

Dashboard configurations are applied through Horizon’s file. The sample configuration file is available from the Horizon repository.

1. Networking

Depending on the Networking backend (Neutron) used in the cloud, Sahara panels will determine automatically which input fields should be displayed.

If you wish to disable floating IP options during node group template creation, add the following parameter:



2. Different endpoint

Sahara UI panels normally use data-processing endpoint from Keystone to talk to Sahara service. In some cases it may be useful to switch to another endpoint, for example use locally installed Sahara instead of the one on the OpenStack controller.

To switch the UI to another endpoint the endpoint should be registered in the first place.

Local endpoint example:

$ openstack service create --name sahara_local --description \
  "Sahara Data Processing (local installation)" \

$ openstack endpoint create --region RegionOne \
  data_processing_local public\(project_id\)s

$ openstack endpoint create --region RegionOne \
  data_processing_local internal\(project_id\)s

$ openstack endpoint create --region RegionOne \
  data_processing_local admin\(project_id\)s

Then the endpoint name should be changed in under the module of sahara-dashboard/sahara_dashboard/api/

# "type" of Sahara service registered in keystone
SAHARA_SERVICE = 'data_processing_local'

3. Hiding health check info

Sahara UI panels normally contain some information about cluster health. If the relevant functionality has been disabled in the Sahara service, then operators may prefer to not have any references to health at all in the UI, since there would not be any usable health information in that case.

The visibility of health check info can be toggled via the SAHARA_VERIFICATION_DISABLED parameter, whose default value is False, meaning that the health check info will be visible.