c4d7e9b8a9
Previously, maintenance requests created on HTTP failures were never automatically resolved. Operators had to close them manually, with no traceability of when or why the request was closed. This commit adds automatic resolution when a service returns HTTP 200 while an open maintenance request exists for it. **Detection logic** (in ``cron_check_http_services``): Before pass 1, the cron takes a snapshot of all services that currently have an open (non-done) ``maintenance.request`` via ``http_maintenance_request``. After pass 1, services in that snapshot that are now OK (``http_status_ok = True``) are identified as recovered and passed to the new ``_close_http_maintenance_request()`` method. **Closure logic** (new ``_close_http_maintenance_request`` method): 1. Finds the first ``maintenance.stage`` with ``done = True``. If none exists (misconfigured instance), the method is a no-op. 2. Moves the ``maintenance.request`` to that done stage via ``sudo()`` to bypass ACL restrictions from the cron user context. 3. Posts a chatter note on the request as OdooBot (``base.partner_root``) using ``subtype_xmlid="mail.mt_note"`` (internal note, not a follower notification) indicating the service URL and that the closure was performed automatically by the monitoring cron. 4. Clears ``http_maintenance_request`` on the ``service.instance``, allowing a fresh request to be created if the service fails again. **Tests** (2 new, 16 total): - ``test_service_recovery_closes_request``: full end-to-end scenario — first cron run produces a KO request, second cron run with HTTP 200 asserts the request is in a done stage, the chatter note mentioning the service URL exists, and ``http_maintenance_request`` is cleared. - ``test_no_close_when_no_open_request``: calling ``_close_http_maintenance_request`` on a service with no open request is a no-op and does not raise. **README**: "Automatic Maintenance Requests" section extended with the recovery behaviour (done stage, OdooBot note, field cleared).
=================================== maintenance_service_http_monitoring
This module provides automated HTTP availability monitoring for services defined on maintenance equipment. It periodically checks the HTTP status of service URLs and automatically creates maintenance requests when services are detected as unavailable.
Key features:
- Automated HTTP checks: Scheduled cron job checks all active services
- Maintenance mode: Temporarily disable monitoring during planned maintenance
- Automatic maintenance requests: Creates corrective maintenance requests when services fail HTTP checks
- Status tracking: Records last HTTP status code and check date per service
Installation
Use Odoo normal module installation procedure to install
maintenance_service_http_monitoring.
This module depends on:
maintenancemaintenance_server_data
Python dependencies: This module requires the requests library.
Configuration
Maintenance Mode Duration
By default, maintenance mode lasts 4 hours. To change this:
- Go to Settings > Technical > System Parameters
- Create or edit the parameter:
- Key:
maintenance_service_http_monitoring.maintenance_mode_duration - Value: Duration in hours (e.g.,
8)
- Key:
Cron Jobs
Two scheduled actions are installed:
-
HTTP Service Monitoring: check all services
- Runs every 15 minutes
- Checks HTTP status of all active service instances with URLs
-
HTTP Service Monitoring: deactivate expired maintenance mode
- Runs every 15 minutes
- Automatically disables maintenance mode when the end time is reached
Webhook Notifications
Go to Settings > Technical > Parameters > System Parameters and configure:
+--------------------------------------------------------+----------------------------------------+
| Key | Description |
+========================================================+========================================+
| maintenance_service_http_monitoring.webhook_url | Webhook URL (POST endpoint) |
+--------------------------------------------------------+----------------------------------------+
| maintenance_service_http_monitoring.webhook_user | Basic Auth username (optional) |
+--------------------------------------------------------+----------------------------------------+
| maintenance_service_http_monitoring.webhook_password| Basic Auth password (optional) |
+--------------------------------------------------------+----------------------------------------+
Usage
Monitoring Services
Services are automatically monitored if they have:
- A service URL defined
- An associated equipment
- The equipment is not in maintenance mode
- The service instance is active
The monitoring checks HTTPS availability (HTTP URLs are automatically upgraded to HTTPS). A service is considered OK if it returns HTTP 200.
Using Maintenance Mode
When performing planned maintenance on a server:
- Go to Maintenance > Equipments
- Open the equipment record
- Click "Activer le mode maintenance" (Activate maintenance mode)
- HTTP monitoring is suspended for this equipment
- The mode automatically expires after the configured duration
- Or click "Désactiver le mode maintenance" to end it manually
Viewing HTTP Status
On service instances, you can see:
- Last HTTP Status Code: The last received HTTP status (200, 404, 500, etc.)
- Last HTTP Check Date: When the last check was performed
- HTTP Status OK: Quick visual indicator of service health
Automatic Maintenance Requests
When a service fails HTTP checks:
- A corrective maintenance request is created per failing service, named
[HTTP KO] {service_url} - The request description includes the error detail: the HTTP status code, or a network error label (timeout / DNS / SSL) when no HTTP response was received
- No duplicate is created as long as an open request already exists for that service
- A double-check is performed before creating the request: the service is retested after 2 seconds. A maintenance request is only created if the service fails both checks, reducing noise from transient HTTP errors
When a service recovers (returns HTTP 200 after having an open request):
- The open maintenance request is automatically moved to the first done stage
- A chatter note is posted on the request by OdooBot to record the automatic closure
- The link between the service and the request is cleared, allowing a new request to be created if the service fails again in the future
Webhook notifications
When a new maintenance request is created (HTTP check failure), the module can send a webhook notification to an external service (e.g., n8n, Rocket.Chat, Slack).
The webhook sends a JSON POST with the following structure::
{
"id": 42,
"name": "[HTTP KO] Server Name",
"priority": "2",
"description": "Service KO: https://example.com",
"equipment": "Server Name",
"link": "https://odoo.example.com/web#id=42&model=maintenance.request&view_type=form"
}
Known issues / Roadmap
- Add configurable alert thresholds (e.g., alert after N consecutive failures)
- Add email/notification on service failure
- Support custom HTTP check endpoints (e.g., /health)
- Add support for basic authentication
Bug Tracker
Bugs are tracked on our issues website. In case of trouble, please check there if your issue has already been reported. If you spotted it first, help us smashing it by providing a detailed and welcomed feedback.
Credits
Contributors
- Stéphan Sainléger
Funders
The development of this module has been financially supported by:
- Elabore (https://elabore.coop)
Maintainer
This module is maintained by Elabore.