Merge Sahara Dashboard into openstack_dashboard

Registered by Chad Roberts on 2014-03-25

Sahara (https://launchpad.net/sahara), has recently graduated from incubation. As a part of being a full project, we would like to merge the sahara-dashboard into openstack_dashboards.

Source for the Sahara Dashbaord is located at https://github.com/openstack/sahara-dashboard.git

**Testing notes**

In order to test the Sahara UI, you would need an instance of the sahara-api running along with the rest of your stack. Your openstack_dashboard installation uses "openstack.services.data_processing" permission to show/hide the Data Processing PanelGroup.

Alternatively, you could follow the instructions at http://sahara.readthedocs.org/en/latest/userdoc/installation.guide.html to get your own sahara-api up and running.

For a video showing what the Sahara Dashboard can do, please see https://www.youtube.com/watch?v=5ha_3oEcgJ8
(Note, that video was done with the "Sahara dashboard" as a dashboard of its own. For the merge into horizon, "Data Processing" will be a panel group under "Project". The actual functionality shown in the video is correct and fairly current though).

Blueprint information

Status:
Complete
Approver:
David Lyle
Priority:
High
Drafter:
Chad Roberts
Direction:
Approved
Assignee:
Chad Roberts
Definition:
Approved
Series goal:
Accepted for juno
Implementation:
Implemented
Milestone target:
milestone icon 2014.2
Started by
David Lyle on 2014-04-30
Completed by
David Lyle on 2014-07-24

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:bp/merge-sahara-dashboard,n,z

Addressed by: https://review.openstack.org/86614
    Adding python-saharaclient to requirements

Addressed by: https://review.openstack.org/86648
    Adding supporting code for Sahara dashboard

Addressed by: https://review.openstack.org/86898
    Adding hadoop cluster-related panels to Sahara dashboard

Addressed by: https://review.openstack.org/86902
    Adding EDP job related panels to Sahara dashboard

Addressed by: https://review.openstack.org/86920
    Selenium-based tests for the Sahara dashboard

Addressed by: https://review.openstack.org/89846
    Adding plugins panel for Sahara

Addressed by: https://review.openstack.org/89897
    Adding the data_image_registry panel for Sahara

Addressed by: https://review.openstack.org/91011
    Adding nodegroup_template panel for Sahara

Addressed by: https://review.openstack.org/91058
    Adding cluster_template and cluster panels for Sahara

Addressed by: https://review.openstack.org/91081
    Data Sources panel for Sahara

Addressed by: https://review.openstack.org/91091
    Adding Job Binaries panel for Sahara

Addressed by: https://review.openstack.org/91118
    Adding Jobs and Job Executions panels for Sahara

[2014.06.10 jpich] Moving to j-2.

[2014.06.30 lblanchard] Hi Chad, I had a chance to review the youtube demo that was posted finally and wanted to give some comments on the UI design from a UX point of view. I'm not sure that any of these comments should hold up an initial release of the Saraha integration with Horizon, really they are meant to be things we could potentially improve on (like workflows) in the future. Please let me know if you have any questions or comments on these. Also, if there is a better place to post these than the Blueprint I'd be happy to do so.

1) Rather than using the Project name for the section within Horizon, should this be something more descriptive to the end user like Hadoop Clusters? Or should this rather live within a section named “Hardware” that could contain other types of hardware/clusters in the future?
2) It doesn’t seem like there is any breakdown of the features based on roles here. Would any of these things be done by the end user? Are these all administrator tasks? I wonder how we will be able to show/hide certain features to different types of users if they differ.
3) Would the user benefit from seeing a breakdown of the types of instances running in a cluster? (I’m assuming from the cluster template there would be 1 master and 4 workers…
4) I could see fill out the URL for the data source to become very confusing to users to be sure they have the accurate URL. Is there any way we could enhance this to browse for the source?
5) I think the ultimate goal for the user would be to create a certain job. I wonder if we should have more of a workflow focused around the job. Sure it might be nice to be able to see a list of Data Sources and Job Binaries, but would a user ever create these without wanting to run a job? Or I should ask...how over would they do this? Could we model a “Create a Job” workflow closer to “Launch an Instance” where the user needs to define the Data Sources and Job Binaries as the first few steps? I think this would follow the mental model better.
6) While in the “Launch Job” modal, I’m not sure the Configure tab needs the required asterisk. In the example you have shown in the youtube video there was no configuration required so this asterisk should not show.
7) Would it be possible to add some help text to the Configuration, Parameters, and Arguments sections in the Configure tab? When would the user know that they need to fill these out?
8) I’m wondering if Job Executions should be bundled up with Jobs in some way. Should there just be a history in the details page or even a status field in the Jobs table letting the user know about the latest executions of the Job instead of a completely new section?
9) Does it make sense for the “Delete Job execution” button to still be available after the Job has finished running? Would this just be an archive action? Maybe we don’t even need anything for this and it just remains in the table as history? What do the other UIs allow for completed jobs?

Best,
Liz

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.