Provide extensible space in page header for plugins to post content

Registered by Greg Waines

Summary
=======
Provide extensible space in page header for plugins to post content.

Motivation
==========
Some projects have critical data that they would like to make visible
to the user at all times. A specific example would be the Critical,
Major, Minor and Warning active alarm counts from Vitrage. Regardless
of what panel the Horizon user is on, it is useful for the user to be
able to check system alarm counts without having to change panels. Other
projects have expressed similar requirements.

In order to provide this capability, Horizon will provide extensible
space in the page header for plugins to post content.

Description
===========
The existing mechanism for extending Horizon through entries in the 'enabled'
directory, will be extended to support a section that points to a
project-specific template for inclusion in the Horizon header space and a
project-specific view that will provide the data to render this template;
where the code for the template and the view would reside in the
project-specific repo.
i.e.
    ADD_HEADER_SECTION = [(<html-template>, <view>),]

e.g. for Vitrage,
    ADD_HEADER_SECTION = [(‘/vitrage_dashboard/templates/header/header.html’,
                           ‘vitrage_dashboard.alarms.views.BannerView’),]

Then in the Horizon header template, it would include any templates that
exist in a new list compiled in the settings (e.g. ext_header_sections)
in order to include them in the rendering of the page header.

As for populating the data of the header sections, a javascript handler
on page load would send a request to a new extensibleHeader view in Horizon
that will call the views of all included project-specific header sections and
return all of the data or populated templates to be inserted/replaced in the
header.

Optionally, the extensibleHeader view in Horizon could just reference the
project-added templates, leave the headers empty on page load, send non-blocking
queries to project-added views and only populate after the header requests to
the project-added views come back; in order to not have project-header queries
slowing down loading of the overall Horizon page.

UX
==
The area between the regions/project menu and the settings menu in the Horizon
topnavbar will be used for project extensible headers.
i.e.
<reg/proj-menu> <----------- Extensible Header Space ---------> <settings-menu>

The extensibleHeader view in Horizon will manage multiple project header views
such that the Extensible Header Space is divided up vertically between the
project header views.
e.g.
<reg/proj-menu> <-proj_A-specific-hdr-><-proj_B-specific-hdr-> <settings-menu>

Although past a certain number of project-added headers, would need to manage
this differently. For example, provide a menu to select which project-added
header(s) are currently visible.
i.e.
<reg/proj-menu> <---- proj_A-specific-header ----><hdr-select> <settings-menu>

Testing
=======
Regression test Horizon header behaviour if no project-headers are added.

Test with up to 5 added project headers.
Although suspect typical scenario will be only 1 or 2, if any.

Outside Dependencies
====================
None.

Requirements Update Required
============================
Add the requirement of providing extensible space in page header for plugins to
post content, to Horizon requirements.

Doc Impact
==========
Horizon documentation related to the use of the 'enabled' directory needs to be
updated to include the new ADD_HEADER_SECTION syntax and functional description.

Blueprint information

Status:
Complete
Approver:
Rob Cresswell
Priority:
Medium
Drafter:
Greg Waines
Direction:
Approved
Assignee:
Tyler Smith
Definition:
Approved
Series goal:
Accepted for 13.0.0-queens
Implementation:
Implemented
Milestone target:
milestone icon queens-1
Started by
Ying Zuo
Completed by
Tyler Smith

Related branches

Sprints

Whiteboard

[2017-06-15 david-lyle] In general I think this looks good. I worry about the overflow case. The header is responsive to window width changes now and we should maintain that. I think the trivial fix now will be overflow hidden, but I'd like us to think about a better answer. But I'm not sure that warrants blocking moving forward with this.

[2017-06-16 robcresswell]
Conceptually, this is fine. There are some bits to work out, but that can be done in the review process. I tend to look on blueprints as "is this a feature we want, and does the approach and considerations in place sound reasonable" and this meats those criteria.

One thing, for example, is that since views can already define templates anyway, the (view, class) tuple seems a little redundant. You could probably just have a list of classes.

The other consideration is angular. You could probably just define this as a list of components to render (i.e. <vitrage-alarms></vitrage-alarms>) and just pass that in as a list in the settings, like so:

ADD_HEADER_SECTION = [
    "vitrage-alarms"
]

Gerrit topic: https://review.openstack.org/#q,topic:bp/extensible-header,n,z

Addressed by: https://review.openstack.org/484899
    Adds extensible header functionality

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.