|
| 1 | +--- |
| 2 | +title: Week 6 |
| 3 | +author: Divij Sharma |
| 4 | +tags: [gsoc24, rest] |
| 5 | +--- |
| 6 | + |
| 7 | +<!-- |
| 8 | +SPDX-License-Identifier: CC-BY-SA-4.0 |
| 9 | +
|
| 10 | +SPDX-FileCopyrightText: 2024 Divij Sharma <divijs75@gmail.com> |
| 11 | +--> |
| 12 | + |
| 13 | +# Week 6 meeting and activities |
| 14 | + |
| 15 | +_(July 02,2024)_ |
| 16 | + |
| 17 | +## Attendees |
| 18 | + |
| 19 | +- [Divij Sharma](https://github.com/dvjsharma) |
| 20 | +- Katharina Ettinger |
| 21 | +- [Shaheem Azmal M MD](https://github.com/shaheemazmalmmd) |
| 22 | + |
| 23 | +## Discussion |
| 24 | + |
| 25 | +- Gave updates and demo on previous week's work. |
| 26 | +- Discussed on the endpoint requirements for the Jobs API. |
| 27 | + |
| 28 | +## Activities |
| 29 | + |
| 30 | +- Modified `/jobs`, `/jobs/{id}`, `/jobs/all` endpoints considering the following points: |
| 31 | + |
| 32 | + 1. Currently, the structure of the `jobs` object returned by these endpoints is as follows: |
| 33 | + ```json |
| 34 | + [ |
| 35 | + { |
| 36 | + "id": <job id>, |
| 37 | + "name": <name of the job (upload name)>, |
| 38 | + "queueDate": <job queue date>, |
| 39 | + "uploadId": <upload id of the package>, |
| 40 | + "userId": <user id of the user>, |
| 41 | + "groupId": <group id of the user>, |
| 42 | + "eta": <time left>, |
| 43 | + "status": <job status (completed, killed, failed, etc.)> |
| 44 | + } |
| 45 | + ] |
| 46 | + ``` |
| 47 | + This structure has the following problems, as outlined in #[1301](https://github.com/fossology/fossology/issues/1301), #[1800](https://github.com/fossology/fossology/issues/1800) and #[1972](https://github.com/fossology/fossology/issues/1972). |
| 48 | + |
| 49 | + - The structure is very simple, and does not provide much information about the job. |
| 50 | + - For example, the `agent` triggered by the job is not present in the response. |
| 51 | + - There is no information about child jobs being executed, and what is the status of each child job. |
| 52 | + - The information about `status` is redundant and returns invalid response for some testcases. |
| 53 | + - (After queue was added) The parent job status is determined by the success/failure of all the jobs related to that specific upload, and not the child jobs. |
| 54 | + - This, along with the current structure, makes it impossible to determine what exactly failed. |
| 55 | + |
| 56 | + 2. To handle all the things mentioned in point 1, I modified the structure as: |
| 57 | + ```json |
| 58 | + [ |
| 59 | + { |
| 60 | + "id": <job id>, |
| 61 | + "name": <name of the job (upload name)>, |
| 62 | + "queueDate": <job queue date>, |
| 63 | + "uploadId": <upload id of the package>, |
| 64 | + "userId": <user id of the user>, |
| 65 | + "groupId": <group id of the user>, |
| 66 | + "eta": <time left>, |
| 67 | + "status": <job status (completed, killed, failed, etc.)>, |
| 68 | + "jobQueue": [ |
| 69 | + { |
| 70 | + "jobQueueId": <job queue id>, |
| 71 | + "jobQueueType": <job queue type (generally agent name)>, |
| 72 | + "startTime": <job queue start time>, |
| 73 | + "endTime": <job queue end time>, |
| 74 | + "status": <job queue completion statu>, |
| 75 | + "itemsProcessed": <number of items processed>, |
| 76 | + "log": <location of log file if exists>, |
| 77 | + "dependencies": <Array: list of dependent job queue ids>, |
| 78 | + "itemsPerSec": <number of items processed per second>, |
| 79 | + "canDoActions": <job can accept new actions like pause and cancel>, |
| 80 | + "isInProgress": <checks if the job queue is still in progress>, |
| 81 | + "isReady": <is the job ready>, |
| 82 | + "download": { |
| 83 | + "text": <text for download link>, |
| 84 | + "link": <link to download the report |
| 85 | + } |
| 86 | + } |
| 87 | + ] |
| 88 | + } |
| 89 | + ] |
| 90 | + ``` |
| 91 | + This structure provides a lot more information about the job, and also provides information about the child jobs being executed, and what is the status of each child job. Attaching a screenshot of the response below. |
| 92 | + |
| 93 | +  |
| 94 | + |
| 95 | + 3. The same structure is used for the `/jobs/{id}` and `/jobs/all` endpoints. |
| 96 | + |
| 97 | + 4. The status returned by the endpoints now depend solely on the status of the child jobs, and not all the jobs related to the upload. |
| 98 | + |
| 99 | + Uplink PR [feat(api): New endpoints to get/delete/restore/update scancode copyright, email, author, url findings](https://github.com/fossology/fossology/pull/2781) |
| 100 | + |
| 101 | +- Worked on documenting some improvements in the REST API implementation. |
0 commit comments