Fix ngen entrypoint script for geopackage hydrofabrics #624
Conversation
Fixing to properly support geopackage hydrofabric dataset type in commands to execute ngen if that is what is provided; also adding creation of a symlink to output dataset in fixed location for routing.
| @@ -48,6 +48,10 @@ init_ngen_executable_paths | |||
|
|
|||
| # Move to the output dataset mounted directory | |||
| cd ${OUTPUT_DATASET_DIR:?Output dataset directory not defined} | |||
| #Needed for routing | |||
There was a problem hiding this comment.
Is this hard coding intentional? I don't see any other references to /dmod/dataset/experiment_output and we should probably stay away from just naming stuff some form of experiment - we're still stuck with that in the GUI.
There was a problem hiding this comment.
The hard coding is intentional. In short, we need to configure something in advance that will line up with something not known until runtime.
A troute config file needs to include the path to the ngen output (and its own output). But job worker have datasets mounted in as a directory with the same name as the dataset itself. Output dataset names are based on the job id, and that is dynamically generated (at least usually).
I realized after setting this up that we don't absolutely have to do this now, but I decided to leave it in. I could take it out, but it's a problem we eventually will have to deal with, in which case, why not at least do this for now?
I also don't object to changing the name of the symlink, if you have a strong preference about that.
There was a problem hiding this comment.
FYI @christophertubbs, I opened #627 for this. Let me know if you think this needs to come out, or can be left in as a temporary fix.
There was a problem hiding this comment.
Hey, there's a ticket, so I'm good.
|
|
||
| #Capture the return value to use as service exit code | ||
| NGEN_RETURN=$? | ||
| if [ -e ${HYDROFABRIC_DATASET_DIR}/catchment_data.geojson ]; then |
There was a problem hiding this comment.
These are probably more evidence that we need to bump the priority for the ticket for moving logic into python. It might just be because I generally avoid too much shell scripting, but I find this hard to read/track. It doesn't break convention with the rest of the script, so moving that out to another language isn't in the scope of this task.
Fixing to properly support geopackage hydrofabric dataset type in commands to execute ngen if that is what is provided.
Also adding creation of a symlink to output dataset in fixed location for routing.