[change] Evaluate moving RADIUS monitoring integration to openwisp-monitoring

[nemesifier]

Is your feature request related to a problem? Please describe.
OpenWISP RADIUS has an optional Monitoring integration in openwisp_radius.integrations.monitoring. This integration currently registers Monitoring metrics and charts, writes RADIUS accounting and user registration metrics, connects to the radius_accounting_closed signal, provides dashboard charts, includes migrations for general metrics, and includes a management command for rebuilding RADIUS accounting metrics.

With OpenWISP Monitoring adding support for additional time series database backends, such as InfluxDB 2 and Elasticsearch, the RADIUS integration may need to maintain backend-specific chart queries too.

This raises a few concerns that may be worth evaluating:

• Adding support for a new time series database may require changes in both openwisp-monitoring and openwisp-radius.
• Time series database query syntax is not specific to RADIUS and may fit better in the Monitoring module.
• Keeping backend-specific queries in RADIUS may duplicate patterns already present in Monitoring backend query bundles.
• The current RADIUS integration mostly uses Monitoring abstractions for writing metrics, but chart query definitions and at least one raw delete query are backend-specific.

Describe the solution you'd like
It may be worth investigating whether the RADIUS Monitoring integration, or part of it, should move to openwisp-monitoring as an optional integration app, for example openwisp_monitoring.integrations.radius.

This could allow Monitoring to own the TSDB-specific parts of the integration, including chart queries for InfluxDB 1, InfluxDB 2, Elasticsearch, and any future backend. RADIUS could remain focused on exposing the domain data and signals needed by the integration.

Possible shape to evaluate:

• Add an optional RADIUS integration app in openwisp-monitoring.
• Keep the integration isolated from core Monitoring behavior.
• Move RADIUS chart query definitions to Monitoring-side backend query bundles or another Monitoring-owned backend abstraction.
• Keep RADIUS-specific metric writing and signal handling only where it makes sense after further analysis.
• Preserve compatibility for existing projects using openwisp_radius.integrations.monitoring, possibly through a temporary deprecated shim.
• Avoid duplicate metric and chart registration if both old and new paths are installed.

Potential benefits:

• Backend-specific queries could be maintained in the module that owns the TSDB abstraction.
• Adding a new TSDB backend could require fewer cross-repository changes.
• Test coverage for backend-specific query behavior could live closer to the backend implementation.
• RADIUS could avoid carrying TSDB-specific logic that is not part of its core domain.
• The integration could remain optional for deployments that use both RADIUS and Monitoring.

Potential concerns:

• openwisp-monitoring would gain optional knowledge of RADIUS models, signals, registration methods, and accounting semantics.
• Releases may need coordination so Monitoring supports the expected RADIUS versions.
• Migration history needs care because the current integration app label is openwisp_radius_monitoring.
• Existing documentation and project settings reference openwisp_radius.integrations.monitoring.
• A compatibility layer may be needed to avoid breaking existing installations.
• The dependency boundary should remain clean so Monitoring core does not become coupled to RADIUS.

One migration detail to research is whether the moved integration should preserve the existing Django app label openwisp_radius_monitoring, which may reduce migration disruption.

Describe alternatives you've considered
Keep the integration in openwisp-radius and add query definitions for each supported backend there.

This is likely the smallest short-term change, but every new TSDB backend may still require updates in RADIUS.

Expose a more generic query registration or extension API from Monitoring, while keeping the RADIUS integration in openwisp-radius.

This may reduce duplication without moving the whole integration, but it may still leave backend-specific query ownership split across modules.

Move only the TSDB query definitions to Monitoring and keep tasks, signal receivers, migrations, and docs in RADIUS.

This may be a lower-risk middle ground, but it could create a less obvious split unless the API is well defined.

Additional context
The current RADIUS integration includes at least these pieces:

• openwisp_radius.integrations.monitoring.configuration, which defines RADIUS metric and chart configurations and currently embeds InfluxDB query strings.
• openwisp_radius.integrations.monitoring.tasks, which writes user registration and RADIUS accounting metrics through Monitoring models.
• openwisp_radius.integrations.monitoring.apps, which registers charts, metrics, dashboard charts, and signal receivers.
• openwisp_radius.integrations.monitoring.migrations, which creates general Monitoring metric and chart rows.
• rebuild_radius_accounting_metrics, which uses timeseries_db.query with a backend-specific delete query.
• Tests and docs under the RADIUS repository for this integration.

This issue is intended as a proposal for further analysis rather than a final decision. The main question is whether moving the integration, or moving only the TSDB-specific pieces, would make the long-term architecture easier to maintain as Monitoring supports more TSDB backends.