Auto-images are currently (and always have been) a scheduler feature. The manager renders an image YAML at creation and sends it to the scheduler.
The scheduler periodically (on the first of each month) takes this and creates a scheduler Order with it.
This used to be exactly what we wanted when the config export was an Hotspot JSON because Hotspot JSON is a high-level user-friendly file that references content with Human IDs and not dates files.
Imager YAML on the other side is low-level, machine friendly that describes exactly what to download and where to put it. It thus contains URL to dated files instead of ZIM IDs.
The problem is that now auto-images are recreating images similar to what those were… up until the referenced files are gone, leading to a build failure. example.
To fix this now buggy behavior, I believe the shortest path is:
improve the JSON export that we kept alongside YAML. It's an imager-only import/export format. Lacks options AFAIK.
Add a new manager API endpoint (authenticated) to return an image YAML from a JSON config payload
Scheduler to not use the stored YAML but query manager API using JSON when re-creating
rgaudin
commented
2 months ago
Auto-images are currently (and always have been) a scheduler feature. The manager renders an image YAML at creation and sends it to the scheduler. The scheduler periodically (on the first of each month) takes this and creates a scheduler Order with it.
This used to be exactly what we wanted when the config export was an Hotspot JSON because Hotspot JSON is a high-level user-friendly file that references content with Human IDs and not dates files.
Imager YAML on the other side is low-level, machine friendly that describes exactly what to download and where to put it. It thus contains URL to dated files instead of ZIM IDs.
The problem is that now auto-images are recreating images similar to what those were… up until the referenced files are gone, leading to a build failure. example.
To fix this now buggy behavior, I believe the shortest path is:
optionsAFAIK.