Skip to content

Refactor for cleaner caching in dashboards

Sarah Yasonik requested to merge improve-dashboard-caching into master

What does this MR do?

Context: We have metrics dashboards stored in gitlab-ce and in a project's repository. They are stored as yml files, then when requested by the frontend, are fetched & data from the DB is inserted into the dashboard. The dashboard is cached before inserting db-info (as alerts/metrics/etc can potentially be created/deleted/changed. Tracking those items are out of scope for this MR.) When any dashboards in the project are created/updated/delete, the cache gets updated.

This MR refactors the caching layer in the metrics dashboard API for a couple of reasons:

  • Before this MR, deleted dashboards weren't actually removed from the cache. The deleted #path_available? logic covered that case, but confusingly.
  • As the Monitor-Health team looks at embedding metrics, we'll want a way to manage cache items that don't directly correspond to entire dashboards. To transition to this, cleaning up the cache interface and giving it a new place to live will be helpful.

This MR shouldn't change any behavior and is only a refactor. As such, the existing tests cover all the cases we care about.

Does this MR meet the acceptance criteria?

Conformity

Performance and testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team

Merge request reports