1. Networking¶

Depending on the Networking backend (Nova Network or Neutron) used in thecloud, Sahara panels will determine automatically which input fields should bedisplayed.

While using Nova Network backend the cloud may be configured to automaticallyassign floating IPs to instances. If Sahara service is configured to use thoseautomatically assigned floating IPs the same configuration should be done tothe dashboard through theSAHARA_AUTO_IP_ALLOCATION_ENABLED parameter.

Example:

SAHARA_AUTO_IP_ALLOCATION_ENABLED=True

2. Different endpoint¶

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

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

Local endpoint example:

openstack service create --name sahara_local --description \    "Sahara Data Processing (local installation)" \    data_processing_localopenstack endpoint create --region RegionOne \--publicurl http://127.0.0.1:8386/v1.1/%\(project_id\)s \--adminurl http://127.0.0.1:8386/v1.1/%\(project_id\)s \--internalurl http://127.0.0.1:8386/v1.1/%\(project_id\)s \data_processing_local

Then the endpoint name should be changed insahara.py under the module ofsahara-dashboard/sahara_dashboard/api/sahara.py.

# "type" of Sahara service registered in keystoneSAHARA_SERVICE='data_processing_local'

3. Hiding health check info¶

Sahara UI panels normally contain some information about cluster health. Ifthe relevant functionality has been disabled in the Sahara service, thenoperators 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 theSAHARA_VERIFICATION_DISABLED parameter, whose default value is False,meaning that the health check info will be visible.

Example:

SAHARA_VERIFICATION_DISABLED=True