This is an implementation issue to move our cluster health within the Monitor stage into Core
This should have a seperate MR to update our documentation as well.
we should probably close/verify #219992 (closed) once this issue gets implemented
Technical notes
Related to the core version yml config/prometheus/cluster_metrics.yml, @splattael said: We should then move the EE version into the CE and update the code where the EE version was referenced (#223693 (comment 367479300))
@dhershkovitch and @ClemMakesApps - I think it makes more sense to have cluster health as a new dashboard instead of having the charts on the cluster settings page.
It's likely an easier path (faster delivery to our users) to move to GitLab core than to wait for us to move it into a new dashboard. Last I checked, there is no specific SLO for when we need to complete this but I'm fairly certain we need to do this before December since that's the month we announced this last year
It's likely an easier path (faster delivery to our users) to move to GitLab core than to wait for us to move it into a new dashboard.
Interesting , i thought the opposite, since its just another yml file, what if we do it together with #218649 (closed), so we'll move 2 dashboards (which would bring us to a total of 3 OOTB dashboard), will this be more efficient?
The cluster health charts are available in their existing location, even without deployments or environments. An environment isn't required for those charts (since they're monitoring only the cluster), but if they were moved exclusively to Operations > Metrics as a dashboard, users would be required to have a successful deployment to view them... That seems like a pretty big disadvantage.
@syasonik we have an issue about decoupling environments (#213833 (closed)) but your point is completely true and a blocker for moving cluster health dashboards to the out of the box dashboards
Cluster health dashboards can also be tied to the group level IIRC (If I recall correctly) which adds another level of complexity. I'm fairly certain moving to core is an easier step.
Please provide a quick summary of the current status (one sentence).
I plan to split backend work in at least 2 MRs one which clears permissions
!35333 (merged) (already in the maintainer review)
and one for moving controller and services code
When do you predict this feature to be ready for maintainer review?
First MR is at maintainer review, and I plan to move second one to maintainer review on wednesday
Are there any opportunities to further break the issue or merge request into smaller pieces (if applicable)?
I may split moving controllers and services in to two separate MRs
Please provide a quick summary of the current status (one sentence).
I've underestimated backend effort required to complete this issue, as a result I've split work into 5 MRs and one MR which I've moved under scope of follow up issue since it should not block moving cluster health to the core. 2 MRs are already merged, 1 is in the maintainer review and 2 are still in development
When do you predict this feature to be ready for maintainer review?
I hope all MR will be merged or in maintainer review in the first half of the next week