feat: reference local path for inputs to run the GCBM example

[Namyalg]

Pull Request Template

Description

This PR enables referencing a local path to supply inputs to the GCBM example. A volume is mounted onto the container, which is referenced in app.py. This eliminates the need to POST files at the /gcbm/upload endpoint.
The documentation has been updated accordingly.

Fixes #83

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How Has This Been Tested?

Testing has been performed by building the docker image and running the API endpoints

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have tagged the reviewers in a comment below incase my pull request is ready for a review

[Namyalg]

@HarshCasper @aornugent , currently this works for the inputs, should this be extended to the output folder too?

[aornugent]

Hey @Namyalg -

Because FLINT.cloud can be run both locally and remotely, I think it might be better to introduce a second endpoint to change the path in the scenario where input files are mounted and available locally.

This way there would a user would have two options:

1. Set a local path and index any available input files
2. If there are no input files available, upload them to the app

Are you able to change this to leave the upload endpoint intact and have a second endpoint for indexing locally available files?

[Namyalg]

Yes, I think that can be achieved
The endpoint /gcbm/upload/:option will be able to handle both the cases

1. /gcbm/upload/local_path (which means reference a mounted volume/or local path, as an example can be the unzipped version of GCBM_Demo_Run.zip)
2. /gcbm/upload/app (name can be changed) where the files can be uploaded directly

I was thinking, eliminating the need to POST files to the endpoint will make it easier and reduce the chance of errors as there might be a lot of files to upload (specifically talking about Postman as it does not support folder uploads)

I wanted to understand more about scenario 2, when there are no input files available, does this mean the files are present on the cloud and only their path is accessed ?

[aornugent]

What if we had three endpoints:

1. /path - set the local file path where inputs are stored
2. /check - indexes any files that are stored in the local path and shows them to the user
3. /upload - adds new files to the local path

There should be a sensible default for 1. so that users only need to call this endpoint if they need to change the path. Note: here 'local' refers to a path that can be accessed by the app - if the app is running in a Docker container this might be a mounted volume on the host or a temporary file system that is deleted when the container is stopped.

I wanted to understand more about scenario 2, when there are no input files available, does this mean the files are present on the cloud and only their path is accessed ?

In this scenario, a user might not have access to the volumes of a FLINTcloud container (i.e. it's running on a remote server). When they want to change the input files, they need some way to send them to the server for the container to access. This is the intended use case of the /upload endpoint.

[Namyalg]

In my understanding,
/path : create a directory if not existent, this will house the input folders (currently the input folder is expected to have layers, input_database and config)
/check : present the contents of the input folder
/upload : add files/folders to the directory referenced by /path (In case of a docker container, a volume could be mounted right at the start)