View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008874 | Taler | sandcastle (containerized demo deployment) | public | 2024-05-27 20:50 | 2024-10-07 00:00 |
| Reporter | Florian Dold | Assigned To | dvn | ||
| Priority | high | Severity | minor | Reproducibility | have not tried |
| Status | assigned | Resolution | open | ||
| Product Version | git (master) | ||||
| Target Version | 1.0 stretch goals | ||||
| Summary | 0008874: host systemd service should have health check for successful provisioning inside container | ||||
| Description | That way we know whether the service started up properly without having to enter the container. | ||||
| Tags | No tags attached. | ||||
|
|
Can you provide some more info on what you mean here Florian? Specifically what all should we be waiting on to come up before saying it's healthy? |
|
|
I think there are two aspects to this: 1. Better checks that deployed components are actually working *inside* the setup script. We could just use the wallet here (with values taken from the sandcastle config) and run this: taler-wallet-cli api --expect-success 'runIntegrationTestV2' '{"exchangeBaseUrl": "https://exchange.demo.taler.net/", "corebankApiBaseUrl": "https://bank.demo.taler.net/", "bankBaseUrl": "https://bank.demo.taler.net/", "merchantBaseUrl": "https://backend.demo.taler.net/", "merchantAuthToken": "secret-token:sandbox" }' 2. *Some* way to expose to the host whether the deployment came up successfully or not. Imagine that I'm updating taler-test@taler. net to the latest component versions. How do I know that it came up successfully without manually having to enter the container and look at the status of the setup-sandcastle.service? |
|
|
I have the check running in the setup script based on your taler-wallet-cli API. For the second goal, I am attempting to configure a sane podman "healthcheck" configuration[0] that will use systemctl to check the status of the taler services, with a reasonable start-up wait time and number of retries. [0] https://developers.redhat.com/blog/2019/04/18/monitoring-container-vitality-and-availability-with-podman |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-05-27 20:50 | Florian Dold | New Issue | |
| 2024-05-27 20:50 | Florian Dold | Status | new => assigned |
| 2024-05-27 20:50 | Florian Dold | Assigned To | => dvn |
| 2024-06-24 02:52 | dvn | Note Added: 0022715 | |
| 2024-06-26 18:07 | Christian Grothoff | Target Version | 0.12 => 0.13 |
| 2024-07-25 21:31 | dvn | Status | assigned => feedback |
| 2024-07-25 21:31 | dvn | Assigned To | dvn => Florian Dold |
| 2024-07-29 12:34 | Florian Dold | Note Added: 0022865 | |
| 2024-07-29 12:34 | Florian Dold | Assigned To | Florian Dold => dvn |
| 2024-08-19 14:49 | dvn | Status | feedback => assigned |
| 2024-08-24 20:38 | Christian Grothoff | Priority | normal => high |
| 2024-08-24 20:38 | Christian Grothoff | Product Version | => git (master) |
| 2024-08-24 20:38 | Christian Grothoff | Target Version | 0.13 => 0.14 |
| 2024-08-25 18:03 | dvn | Note Added: 0023061 | |
| 2024-10-07 00:00 | Christian Grothoff | Target Version | 0.14 => 1.0 stretch goals |
