Skip to content

Draft: Setting up persistent storage for delivery-metrics(WIP)

Maina Ng'ang'a requested to merge an/persist-to-consul into master

What does this MR do and why?

This MR will test our read and write capabilities on the consul server which runs in the ops environment. We will write a dummyKey with a dummyValue.

We had three possible ways we could have stored delivery-metrics K/V data:

  • In Redis
  • Consul
  • Google memory store

Redis was ruled out since this process would have involved setting up and managing our own redis instance. Google memory store is another viable option, this is still under discussions. We plan to compare the two options before deciding on the most appropriate method. Consul service is fully operational and accessible from the ops instance among other pros and cons, but if Google memory store turns out to be the better option we can easily switch to it.

Content

When the delivery-metrics app is deployed, it doesn't "remember" anything as it has no DB or memory of any kind. We are implementing a way to store metrics values into consul, since release-tools need to be aware of the current metric in order to determine if the next value is valid.

Related Issue: gitlab-com/gl-infra/delivery#20083

Author Check-list

  • Has documentation been updated?
Edited by Maina Ng'ang'a

Merge request reports