OpenStack Dashboard (Horizon)

OpenStack_dashboard.dashboards decoupling

Registered by LIU Yulong

This is a blueprint to make the dashboards less coupling.

Summary
=======
To make the dashboards less coupling. So the cloud administrator can easily to enable/disable the dashboard. Make the dashboard combination more grace.

Description
=========
Now horizon has 5 dashboards, admin, project, router, settings, identity.
But there are form calls, template use, table use, between each dashboard components.
One scenario is that Horizon was deployed on different servers. For one deployment, just enable the project dashboard. For another just enable admin dashboard. Now this scenario can not be done by only settings in enabled folder. If you do that, e.g. disable the project dashboard, it will ordinarily rise some template not found error.

Motivation
========
The purpose is to reduce the coupling while one dashboard is not enabled.
To abstract universal forms, tables, functions, etc. is a potential method.

Blueprint information

Status:
Complete
Approver:
David Lyle
Priority:
Medium
Drafter:
LIU Yulong
Direction:
Approved
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
David Lyle

Related branches

Sprints

Whiteboard

[2014-11-17 | david-lyle] I like the idea here, but I'd like to see a plan.

[LIU Yulong Dec-11-2014], Hi david, I plan to add a package like openstack_dashboard.dashboard_common. In this common package to implement some base classes or htmls like instance (volume, network, etc) table, form, templates. Then both admin-dashboard and project-dashboard could inherit these base classes or html templates. I also want to say this common packge is not django app or some dashboard needed to be enabled or installed. I think the most important work of this bp is to figure out all the common code.

[LIU Yulong Dec-11-2014], Currently admin dashboard import the following form project dashboard:

images: forms, tables, views;
instances: tables, views, workflows;
networks ports: forms, views, tables;
networks subnets: forms, views, tables, workflows;
networks: tables, tests, views;
routers ports: tables, tabs;
routers: forms, tables, tabs, tests, views;
volumes snapshots: tables, tabs, views;
volumes volumes: tables, views;
volumes: tabs;

[david-lyle | 2015-08-12] The reasoning is sound, but I haven't seen any progress. Additionally, the eventual conversion to angular JS should resolve much of this.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.
Edit subscription

Subscribers

No subscribers.