PIPELINE: Draft version for the API

[ansonwong9695]

Created 3 endpoints for the front end

• /job: which receive the post request from the front end, use to activate the pipeline
• /job//status : this endpoint allows query about the status on specific job and return the job status to the front end
• /api/v1/pipelines: this endpoint allows front end to know the information of each pipelines

Create 1 endpoints to update the status internally

• /status: which allow the pipeline update the status dictionary when they finished a section of task

Other functionality -create the clean up function for the status, if job exist more than 20 mins will be deleted. -pipeline when finished the task it will send the request to the hologram (have not tested it)

[nielsboecker]

Good morning :) Thanks for opening the PR, Kawai. Some general remarks:

• When I meant prefix /api/v1/, I meant for all routes, not just /pipelines. You can read more about this stuff here, but please change to be all routes.
• Please merge dev back into your branch and resolve the merge conflicts.
• Please resolve the CodeFactor issues.

[nielsboecker]

@ansonwong9695, @UdomkarnBoonyaprasert: I have some other TODOs for you guys; we can track them in this post and cross them out when you finished them:

• [x] I see an architectural problem: Initially, we said both the data fetching from PACS and the data posting to Accessor should be their own components, that can be part of each pipeline. In your code however, the fetching gets done right in the server, whereas the posting gets done at another level (in each pipeline). Please refactor.
• [ ] You need to clean up after yourselves. What happens with all the input files you download after the job is finished? They will stay there forever, currently. Also they will all be in the same directory, it is impossible to keep track what came from where. Potentially there can even be issues if different pipelines try to download a file with the same name at the same time. How about creating a folder jobs/<jobid> for each job. jobs/<jobid>/input for your stuff from the PACS and jobs/<jobid>/output for what you are generating; and then maybe deleting that once stuff gets removed from the status? @boonwj any other ideas? NOT done. Shall be done in a new PR.
• [x] You should add flask to your dependencies.txt
• [ ] You should update the README on how to start the server and document the endpoints. I do it in the refactoring branch
• [x] There are two empty files, please remove: pipelines/components/compStoreGLB and pipelines/components/compOutputGLB
• [ ] You should add a Dockerfile (this can be a separate PR, but don't forget it) => different PR
• [ ] There should be more error handling (you always expect that all fields are coming exactly as expected, but what happens otherwise?) - can be a separate PR

[nielsboecker]

Sorry @ansonwong9695, I realised that the build for your work was broken all along. I fixed several issues with the imports, but the tests still fail. I think it is because you changed the main method signature (using the object to bundle all the arguments). But you did not change the tests to reflect that. Can you please update the tests?

[nielsboecker]

Update: I found that the tests fail for different reasons actually, including @UdomkarnBoonyaprasert's changes. It's a big, big, mess to be honest. I disabled the tests for now, and you can fix them later (in a different branch!)

[nielsboecker]

Note that there are still many issues in this branch at the time of merging, especially in compJobPath. I am merging it now to prevent future merge conflicts, as I am doing a heavy refactoring in #45 . In that branch I also fix most issues. The "compJobPath" issues can be solved in #59.