[24/10/2024]: Community Call

[sujaya-sys]

Call with Alen, platform engineer, who provided some valuable feedback on the project:

Documentation

• Conduct general clean up (e.g. ensure consistent capitalization)
• Rethink structure: The readme starts by highlighting "development" topics, we should instead move "usage" focused content to the top

feature requests (Added notes to the corresponding issue)

• Allow installation via Helm: Feature Request: Add installation option via Helm #42 (comment)
• Add support for Checkly Agent: Feature Request: Add support for Checkly's private locations #43 (comment)
• Auto provisioning via Ingress: Improve configuration via ingress object annotations #46 (comment)
• API Checks: Keep it lean - the suggestion is to not allow the creation of multiple endpoint checks within one API check configuration to avoid bloated config files

Security

• Teams often work with tools that enforce cluster- and namespace scoped policies e.g. to determine which users/roles can manage certain objects
• We might want to look into the operator taking these kind of security settings / policies into account i.e. only allow users with certain permissions to create / modify checks for example

Observability

• We should emit prometheus metrics from the operator / agent pods
• It'll also be great to allow for the creation of standard resources (such as pod / service monitor components) that can be automatically be picked up by prometheus
• Configuration of prometheus rules would be equally helpful i.e. define what you want to be alerted on

[akosveres]

We should emit prometheus metrics from the operator / agent pods

We currently do this for the operator pods, there are default metrics from the kubebuilder project: https://github.com/checkly/checkly-operator/blob/main/cmd/main.go#L60 - We should emit extra metrics which are related to the calls we make to the checklyhq.com APIs.