chart(selenium-grid): add ServiceMonitor and PodMonitor support for Prometheus Operator

[DrFaust92]

Motivation

Users running kube-prometheus-stack currently have no native way to scrape the Selenium Grid metrics exporter via Prometheus Operator. The only option is to configure additionalScrapeConfigs manually. This PR adds first-class ServiceMonitor and PodMonitor support.

Changes

• Named container port (metrics) on the exporter Deployment — explicit port referencing instead of a magic number
• Service port targetPort updated to reference the named port metrics (port name http-port preserved — no breaking change)
• monitoring-service-monitor.yaml — new ServiceMonitor resource scraping the exporter Service on port http-port
• monitoring-pod-monitor.yaml — new PodMonitor resource scraping exporter Pods directly on port metrics (alternative for users without a Service)
• values.yaml — new monitoring.serviceMonitor.* and monitoring.podMonitor.* blocks; both disabled by default

Usage

# ServiceMonitor (scrapes via Service)
monitoring:
  enabled: true
  serviceMonitor:
    enabled: true
    interval: 30s
    scrapeTimeout: 10s
    labels:
      release: kube-prometheus-stack  # match your Prometheus operator selector

# PodMonitor (scrapes pods directly — alternative)
monitoring:
  enabled: true
  podMonitor:
    enabled: true

Testing

# ServiceMonitor
helm template test charts/selenium-grid/ --set monitoring.enabled=true --set monitoring.serviceMonitor.enabled=true

# PodMonitor
helm template test charts/selenium-grid/ --set monitoring.enabled=true --set monitoring.podMonitor.enabled=true

Both render valid monitoring.coreos.com/v1 resources with correct port references.

[qodo-code-review]

Review Summary by Qodo

Add ServiceMonitor and PodMonitor support for Prometheus Operator

✨ Enhancement

Walkthroughs

Description

• Add Prometheus Operator ServiceMonitor and PodMonitor resources
• Name exporter container port metrics for explicit referencing
• Update Service targetPort to reference named port metrics
• Add configurable monitoring values for both resource types

Diagram

flowchart LR
  A["Exporter Deployment"] -->|named port metrics| B["Service"]
  B -->|ServiceMonitor| C["Prometheus Operator"]
  A -->|PodMonitor| C
  D["values.yaml"] -->|serviceMonitor config| B
  D -->|podMonitor config| A

Loading

File Changes

1. charts/selenium-grid/templates/monitoring-exporter-deployment.yaml ✨ Enhancement +2/-1

Name exporter container port for monitoring

• Add explicit name: metrics to container port definition
• Enables named port referencing in monitoring resources

charts/selenium-grid/templates/monitoring-exporter-deployment.yaml

---

2. charts/selenium-grid/templates/monitoring-exporter-service.yaml ✨ Enhancement +1/-1

Update Service targetPort to named port

• Change targetPort from numeric value to named port metrics
• Maintains backward compatibility with http-port service port name

charts/selenium-grid/templates/monitoring-exporter-service.yaml

---

3. charts/selenium-grid/templates/monitoring-service-monitor.yaml ✨ Enhancement +33/-0

Add ServiceMonitor resource for Prometheus Operator

• New ServiceMonitor resource for Prometheus Operator integration
• Scrapes exporter Service on port http-port
• Supports configurable interval, timeout, relabelings, and metric relabelings
• Conditional rendering based on monitoring and serviceMonitor enabled flags

charts/selenium-grid/templates/monitoring-service-monitor.yaml

---

View more (2)

4. charts/selenium-grid/templates/monitoring-pod-monitor.yaml ✨ Enhancement +33/-0

Add PodMonitor resource for direct pod scraping

• New PodMonitor resource for direct pod scraping alternative
• Scrapes exporter pods directly on port metrics
• Supports configurable interval, timeout, relabelings, and metric relabelings
• Conditional rendering based on monitoring and podMonitor enabled flags

charts/selenium-grid/templates/monitoring-pod-monitor.yaml

---

5. charts/selenium-grid/values.yaml ⚙️ Configuration changes +40/-0

Add ServiceMonitor and PodMonitor configuration values

• Add monitoring.serviceMonitor configuration block with enabled, namespace, labels, annotations,
 path, interval, scrapeTimeout, relabelings, and metricRelabelings
• Add monitoring.podMonitor configuration block with same options as serviceMonitor
• Both monitoring resources disabled by default for backward compatibility
• Includes comprehensive documentation comments for each configuration option

charts/selenium-grid/values.yaml

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Cross-namespace monitor fails 🐞 Bug ≡ Correctness

Description

ServiceMonitor/PodMonitor can be deployed to a user-specified namespace, but the exporter
Service/Pods are always created in the release namespace. Because the monitors don't set any
namespace selector, moving them to another namespace prevents them from selecting the exporter
targets, so scraping won't happen.

Code

charts/selenium-grid/templates/monitoring-service-monitor.yaml[R5-20]

+  name: {{ template "seleniumGrid.monitoring.exporter.fullname" $ }}
+  namespace: {{ .Values.monitoring.serviceMonitor.namespace | default .Release.Namespace }}
+  {{- with .Values.monitoring.serviceMonitor.annotations }}
+  annotations:
+    {{- toYaml . | nindent 4 }}
+  {{- end }}
+  labels:
+    {{- include "seleniumGrid.commonLabels" $ | nindent 4 }}
+    {{- with .Values.monitoring.serviceMonitor.labels }}
+    {{- toYaml . | nindent 4 }}
+    {{- end }}
+spec:
+  selector:
+    matchLabels:
+      app.kubernetes.io/name: {{ template "seleniumGrid.monitoring.exporter.fullname" $ }}
+  endpoints:

Evidence

The monitor resources allow overriding metadata.namespace, but their specs only define label
selectors (no namespace selection). Meanwhile the exporter Deployment/Service hardcode namespace to
.Release.Namespace, so targets remain in the release namespace even if the monitor is installed
elsewhere.

charts/selenium-grid/templates/monitoring-service-monitor.yaml[5-20]
charts/selenium-grid/templates/monitoring-pod-monitor.yaml[5-20]
charts/selenium-grid/templates/monitoring-exporter-service.yaml[5-15]
charts/selenium-grid/templates/monitoring-exporter-deployment.yaml[4-19]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ServiceMonitor`/`PodMonitor` support `.Values.monitoring.{serviceMonitor,podMonitor}.namespace`, but the exporter Service/Pods always live in `.Release.Namespace`. Without a `spec.namespaceSelector`, deploying the monitor to a different namespace makes it unable to discover targets.

### Issue Context
The exporter resources are namespaced to `.Release.Namespace`, while the new monitor templates optionally change `metadata.namespace`.

### Fix Focus Areas
- charts/selenium-grid/templates/monitoring-service-monitor.yaml[5-33]
- charts/selenium-grid/templates/monitoring-pod-monitor.yaml[5-33]
- charts/selenium-grid/values.yaml[1044-1084]

### Expected fix
1. Add a configurable `namespaceSelector` block for both ServiceMonitor and PodMonitor (e.g., `monitoring.serviceMonitor.namespaceSelector` / `monitoring.podMonitor.namespaceSelector`).
2. Default it so targets are selected from `.Release.Namespace` (or allow empty `{}` to mean “same namespace” but document clearly).
3. If you keep the `namespace` override, ensure the default behavior (monitor in release namespace) still works unchanged.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Unguarded CRD resources 🐞 Bug ☼ Reliability

Description

When ServiceMonitor/PodMonitor are enabled, the chart renders monitoring.coreos.com/v1 resources
without checking that the Prometheus Operator CRDs are installed. If users enable these while
kube-prometheus-stack is not installed/enabled (or CRDs otherwise absent), Helm will fail due to
unknown kinds.

Code

charts/selenium-grid/templates/monitoring-service-monitor.yaml[R1-3]

+{{- if and (eq (include "seleniumGrid.monitoring.enabled" $) "true") .Values.monitoring.serviceMonitor.enabled }}
+apiVersion: monitoring.coreos.com/v1
+kind: ServiceMonitor

Evidence

The templates only gate on values and immediately emit apiVersion: monitoring.coreos.com/v1
resources; there is no .Capabilities.APIVersions.Has (or similar) check. The chart also treats
kube-prometheus-stack as an optional dependency (conditional), so CRDs may be absent even when these
templates are enabled.

charts/selenium-grid/templates/monitoring-service-monitor.yaml[1-3]
charts/selenium-grid/templates/monitoring-pod-monitor.yaml[1-3]
charts/selenium-grid/Chart.yaml[21-24]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ServiceMonitor`/`PodMonitor` templates render CRD-backed kinds unconditionally when values enable them. If the CRDs are not installed, `helm install/upgrade` fails with an unknown-kind error.

### Issue Context
This chart can be used without enabling the `kube-prometheus-stack` dependency, so CRDs may not be present even if users enable the new monitor resources.

### Fix Focus Areas
- charts/selenium-grid/templates/monitoring-service-monitor.yaml[1-3]
- charts/selenium-grid/templates/monitoring-pod-monitor.yaml[1-3]
- charts/selenium-grid/README.md[1-200]

### Expected fix
1. Add a Helm capability guard to the `if` condition, e.g.:
  - `(.Capabilities.APIVersions.Has "monitoring.coreos.com/v1")` (or the more specific form if preferred)
2. Optionally add a `fail` with a clear message when enabled but CRDs are missing.
3. Document the prerequisite in the chart README (Prometheus Operator CRDs required when enabling these features).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[VietND96]

@DrFaust92, hopefully, this has been done with the end-to-end deployment and test in your local cluster, and confirmed it works as designed and expected.

[DrFaust92]

@DrFaust92, hopefully, this has been done with the end-to-end deployment and test in your local cluster, and confirmed it works as designed and expected.

HI VietND96, weve been extending this chart with the service monitor resource in my company. this is upstreaming it with ability to save on the extra service as a podmonitor is sufficient here

[VietND96]

@DrFaust92, thank you, that's great!