Improve Horizon's Data Architecture

Registered by Rob Cresswell on 2016-05-23

[WIP] Just jotting down thoughts in a public space. The title is intentionally vague because I'm unsure how to phrase this, but will describe the problems below:

Problem(s):
- There is a big desire for cross-region views and controls.
- Project/ Admin is not necessarily a clear split any more.
- Most of the Django Admin Dashboard code is dependent on the Project equivalent, making disabling panels clumsy. For example, the majority of the Admin panels simply extend the Project code with an extra field or two, but this still has a separate code separation and all the respective boilerplate.

Suggested Solutions:
- Drop the "Project/ Admin" idea, and use the panel group as the top level dashboard. This way, the Admin/Project panels can be combined, and we control the data displayed on the page itself through relevant logic (policy etc). Could be as simple as toggle in each page to display data in this project, or across multiple projects/regions.
- We could have a cross-region panel group specifically for large scale async data. This may tie into multiple other efforts, like OSIC working on the overview pages and Searchlight.

Advantages/ end goals:
- Less confusion over what can or can't be done. Actions should be role based, rather than expecting a user to go a panel and then realise its the wrong panel and go to the admin version, only to then have to carry out a massive query just to create X resource.
- Less code to maintain. It seems sensible to manage the appearance of actions or queries sent by parameters, not by duplication/inheritance and redefining actions. A lot of the smaller panels have hundreds of lines of boilerplate and separation just to add an extra form field or a table column.

Other considerations:
- The angular work gives us a good avenue to rewrite this. Currently, they seem to going along the lines of '<horizon_url>/project/details/<resource_type>/<id>' for example. I'd prefer to use <horizon_url>/<resource_name>/<id> etc.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
Rob Cresswell
Direction:
Needs approval
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Not started
Milestone target:
None
Completed by
David Lyle on 2016-10-28

Related branches

Sprints

Whiteboard

[david-lyle | 2016-05-23] I will point out that invoking actions will become interesting with a combined admin/project perspective. This may be doable, but you have to know what role you're wanting to invoke actions with as it will alter what parameters are required by the API.
That's not to say it's not solvable. And once upon a time, I really wanted to combine the project and admin dashboards in Horizon, but the user needs to understand the scope of their actions. Deleting or modifying your things vs deleting or modifying other users' things are very different. The latter should be a very explicit choice. Having mine and others in different dashboards is a clear split.

UX issues that need addressing to make combining the dashboards work:
1) clear indicator of ownership vs not per result
2) very explicit user choice as to scope of the action (the user likely has to choose)
3) handling scope for batch actions

These can be solved of course, I'm just not sure if doing so makes sense.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.