This PR adds support for configurable and decoupled NodeODM servers.
Currently, NodeODM is slightly coupled to the app, in a couple of ways:
The NodeODM URL is hardcoded in a bunch of places (http://container-nodeodm:3000/...)
The post-processing code (run in the webhook that gets called when a Flight finishes processing) assumes that the results can be reached on /flights/uuid/whatever. When the local NodeODM container has control over that folder, the assumption is correct, but when using a remote NodeODM provider, that folder won't even exist.
This PR fixes both problems:
The references to the NodeODM URL have been replaced by a configuration variable that can be easily switched to point to the local NodeODM container (http://container-nodeodm:3000/) or a remote server (https://spark1.webodm.net:443).
The webhook now downloads the results via HTTP (they get downloaded as a ZIP file) and decompresses them on the proper folder (/flights/uuid), after creating the directory. In this way, all post-processing code finds its desired results in the correct place, and everybody is happy.
This PR adds support for configurable and decoupled NodeODM servers. Currently, NodeODM is slightly coupled to the app, in a couple of ways:
http://container-nodeodm:3000/...
)/flights/uuid/whatever
. When the local NodeODM container has control over that folder, the assumption is correct, but when using a remote NodeODM provider, that folder won't even exist.This PR fixes both problems:
http://container-nodeodm:3000/
) or a remote server (https://spark1.webodm.net:443
)./flights/uuid
), after creating the directory. In this way, all post-processing code finds its desired results in the correct place, and everybody is happy.