-
Notifications
You must be signed in to change notification settings - Fork 5
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall the code looks good but I'm not entirely sure that having a table called settings with a single ID column is the best long term solution.
Maybe we should go with a key value approach that will not only cover our current use-case of storing the unique everest instance ID but will allow us to expand it to any other settings that we need to store like default values for a DB engine configuration or whatever.
What do you think about this?
@recharte thanks for the suggestion, the key-value approach sounds great. Updated, PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great 💪
Collect and report metrics
Problem:
EVEREST-507
Report the db engines metrics - how many db clusters of each type are running.
A step forward multi k8s support - generate own Everest ID instead of using the k8s cluster ID.
The telemetry request example
CHECKLIST
Jira
Tests