Middleware is the backbone of the whole profiler facility. It adds an
encoded payload to each request that should be profiled with
osprofiler library. This library is embedded into other OpenStack
services where it tries to decode the message with a known set of keys
(so Horizon middleware should use one of these keys) and if
successful, sends a message to MongoDB (via osprofiler driver). Every
message has its own id, the base id (root message id) and parent
id. Using these 3 ids a tree of trace messages is assembled.
Actually, Horizon Django application uses 2 middleware classes:
ProfilerClientMIddleware and
ProfilerMiddleware. ProfilerClientMiddleware is used to enable Horizon
self-profiling (profiling from the UI): if a specific key is found in
cookies, then 2 standard osprofiler headers are added to a
request. These headers are processed by ProfilerMiddleware which
should always be the last middleware class in a Django config, since
it's defines `process_view` method which returns HttpResponse object
effectively terminating the middleware process_view chain. Assuming
that all API calls happen during rendering a view, Horizon sets a
tracepoint there which becomes a root node of the trace calls tree.
Implements-blueprint: openstack-profiler-at-developer-dashboard
Change-Id: Ib896676e304f2984c011bd1b610c86d1f24d46b9
This patch enables all of the features for the Flavors panel to use Angular but
disables it, so that it is easy to switch on/off.
Note that we add integration test switches since it can't read the Django
conf.
Note that I changed the common tests to allow for testing of api calls that
don't produce error toasts, because we needed better branch coverage, and
the deleteFlavor api wasn't fully branch-tested.
Change-Id: I92b1b57bd486e5eb87179cb8d44b7551e9de2e0f
Partially-Implements: blueprint ng-flavors
We should unify the angular features (new panels, workflows, etc.) in a
single setting. This also makes it a little cleaner to read, simply
using the 'truthiness' of a key rather than string comparisons.
I haven't moved the 'swift_panel' setting, as that panel will be removed
in the O cycle anway, so it seems pointless to move a setting causing
potential issues for a single cycle.
Change-Id: Ia5702ff523355ae895e14cc3d49c895128478944
We want to allow for integration tests to test deprecated panels. This
means that we need to override the configurations provided by the panels
and force a 'legacy' setting.
On the Infra side, we need to pass in an environment variable that tells this
override to be enabled.
Depends-On: I20232ef16ae60a7151e267b506af471ebfed2f7f
Change-Id: If5a3e273098aa726e12f9076c0273a5afaf233d2
Partially-Implements: blueprint test-deprecated-features
The main idea of this change is to not include into Horizon production
code little helper features we need Horizon to have in gating so
Selenium integration tests could easily navigate through it.
Closes-Bug: #1560467
Change-Id: Ib0c973932260ddfe7f1d2cf9fdab7bbbfe298bea
This patch enables the Angular Launch Instance workflow by default. The
toggle has been maintained for those running the Python workflow, and
also for the integration tests to run against both simultaneously.
Keep integration tests running for a legacy Launch Instance workflow
by means of a separate local_settings.d code snippet activated before
starting the tests.
Co-Authored-By: Timur Sufiev <tsufiev@mirantis.com>
Change-Id: Id0c57b33df46397711e32092cec6cc5268841779
Implements: blueprint enable-angular-launch-instance
Horizon themes are now configurable at a user level, through the use
of cookies. The themes that can be set are configurable at a
deployment level through settings.py. Horizon can be configured to
run with multiple themes, and allow users to choose which themes
they wish to run.
Django Compressor:
In order to support dynamic themes, each theme configuration must
be pre-compiled through the Django compressor. By making use of its
built in COMPRESS_OFFLINE_CONTEXT, we now return a generator to
create each of the theme's necessary offline contexts.
Templates:
Horizon themes allowed template overrides via their 'templates'
subfolder. In order to maintain this parity, a custom theme template
loader was created. It is run before the other loads, and simply
looks for a Django template in the current theme (cookie driven)
before diverting to the previous template loaders.
Static Files:
Horizon themes allowed static overrides of the images in
'dashboard/img' folder. A template tag, 'themable_asset' was created
to maintain this parity. Any asset that is wished to be made themable,
given that it is located in Horizon's 'static/dashboard' folder, can
now be made ot be themable. By making this a template tag, this
gives the developers more granular control over what branders can
customize.
Angular and Plugins:
By far, the trickiest part of this task, Angular and Plugins are
dynamic in the files that they 'discover'. SCSS is not flexible in
this manner at ALL. SCSS disallows the importation of a variable
name. To get around this, themes.scss was created as a Django
template. This template is the top level import file for all styles
within Horizon, and therefore, allows ALL the scss files to share a
common namespace and thus, can use shared variables as well as extend
shared styles.
Other:
This change is fundamental, in that it changes the method by which
Horizon ingests its SCSS files. Many problems existing in the
previous implementation, in an effort to make Horizon flexible, its
SCSS was made very inflexible. This patch corrects those problems.
Change-Id: Ic48b4b5c1d1a41f1e01a8d52784c9d38d192c8f1
Implements: blueprint horizon-dynamic-theme
Closes-Bug: #1480427
All files ending with '.py' in local_settings.d/ are evaluated
after reading the settings from local_settings.py . That means
changing the settings can be done without changing local_settings.py .
Change-Id: I0b25ef2c4dada23f8cb66aa5e8af44b3a1cba3b9
Implements: blueprint local-settings-override-mechanism