View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009981 | Taler | deployment and operations | public | 2025-05-19 22:26 | 2026-08-10 10:29 |
| Reporter | Florian Dold | Assigned To | Florian Dold | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | informing | Resolution | fixed | ||
| Product Version | 1.0 | ||||
| Target Version | 1.6 | Fixed in Version | 1.6 | ||
| Summary | 0009981: ansible exchange deployment should do basic checks that the exchange is running properly | ||||
| Description | Currently it is possible for the ansible scripting to succeed, but for the exchange to have a broken config where taler-exchange-httpd doesn't even start properly. | ||||
| Tags | No tags attached. | ||||
| Well, we do now get alerts from prometheus whenever systemd services are failed/not running. Plus uptimekuma should be monitoring /keys and send alerts. what is left? I could imagine us adding some "final" step that *locally* on the client system runs some taler-harness invocation to check the deployment, but I'd not put this host-side. Is there a subcommand we can use for that? | |
| Hmm. I don't think that an ansible deploy should succeed if, say, the configuration is completely borked. So IMO we'd need to either: (a) Check the `/config` endpoint with `ansible.builtin.uri` (b) Check that systemd services are running after starting them (seems a bit unreliable w.r.t. timing) (c) Have some "--check-config" mode for all components that the ansible script runs (extra work) So IMO (a) is probably the easiest, though I'd like to have (c) in the long term (post-2.0?) WDYT? | |
| Sure, let's do (a) for 1.1 and (c) post-2.0. | |
| commit b762722b614360d61a964bf6020d0feb51ef9628 (HEAD -> master) Author: Florian Dold <dold@taler.net> Date: Mon Aug 10 12:05:18 2026 +0200 Add post-deployment sanity checks | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-05-19 22:26 | Florian Dold | New Issue | |
| 2025-05-20 19:52 | Christian Grothoff | Status | new => implementing |
| 2025-06-03 18:02 | Christian Grothoff | Note Added: 0025110 | |
| 2025-06-03 18:02 | Christian Grothoff | Assigned To | => Florian Dold |
| 2025-06-03 18:02 | Christian Grothoff | Status | implementing => feedback |
| 2025-06-05 12:28 | Florian Dold | Note Added: 0025154 | |
| 2025-06-05 12:28 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2025-06-05 18:39 | Christian Grothoff | Note Added: 0025171 | |
| 2025-06-05 18:39 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2025-06-05 18:39 | Christian Grothoff | Severity | minor => feature |
| 2025-06-05 18:39 | Christian Grothoff | Status | feedback => implementing |
| 2025-06-05 18:39 | Christian Grothoff | Product Version | => 1.0 |
| 2025-07-30 08:56 | Christian Grothoff | Assigned To | => Florian Dold |
| 2025-07-30 08:56 | Christian Grothoff | Status | implementing => assigned |
| 2025-08-31 17:20 | Christian Grothoff | Target Version | 1.1 => post-1.0 |
| 2025-12-07 09:53 | Christian Grothoff | Status | assigned => implementing |
| 2026-08-10 10:19 | Florian Dold | Status | implementing => informing |
| 2026-08-10 10:19 | Florian Dold | Resolution | open => fixed |
| 2026-08-10 10:19 | Florian Dold | Note Added: 0029453 | |
| 2026-08-10 10:29 | Christian Grothoff | Fixed in Version | => 1.6 |
| 2026-08-10 10:29 | Christian Grothoff | Target Version | post-1.0 => 1.6 |