For batches there are three API methods (the equivalent experimental API in parenthesis):
- add_api_user (user_create)
- add_batch_job (batch_create)
- get_batch_job_result (batch_status)
add_api_user (user_create)
This method is problematic and by default disabled. It is hard to see the use case of multiple users for batches. I suggest that this method is removed. At the same time, the username and API key concept should be removed.
Instead, introduce a token to be used to authenticate batches. There is no need for separate users. The token is to be configured in the Backend configuration file, which removes the need to have some special interface for setting the user/key. If there is no token in the configuration file, batches are not supported.
- Remove the method
- Update backend to use a token in configuration file instead of user/key
- Remove user table
add_batch_job (batch_create)
There are two changes for this method:
get_batch_job_result (batch_status)
This method should be replaced by the following methods (method names are just draft names):
get_batch_list
Input:
Output:
- The number of tests in the batch.
- A list of all tests in the batch, where each test is given as hash-ID and zone name pair.
This method could result in a lot of data. Maybe paging would help? In the usual case this method is only used once, and then the calling script will cache the data.
get_batch_status
Input:
- Batch ID
- Optionally a list of one or more of the keywords "waiting", "running" and "done"
Output:
- The number ofwaiting tests in the batch (progress = 0).
- The number of running tests (0 < progress < 100).
- The number of completed tests (progress = 100).
- If the keyword "waiting" was included, a list of hash ID of tests where progress = 0
- If the keyword "running" was included, a list of hash ID of tests where 0 < progress < 100
- If the keyword "done" was included, a list of hash ID of tests where progress = 100
This is a method that the calling script will use multiple times, and there is no need to repeat the hash-IDs unless really requested. This method could result in a lot of data. Maybe paging would help?
For batches there are three API methods (the equivalent experimental API in parenthesis):
add_api_user (user_create)
This method is problematic and by default disabled. It is hard to see the use case of multiple users for batches. I suggest that this method is removed. At the same time, the username and API key concept should be removed.
Instead, introduce a token to be used to authenticate batches. There is no need for separate users. The token is to be configured in the Backend configuration file, which removes the need to have some special interface for setting the user/key. If there is no token in the configuration file, batches are not supported.
add_batch_job (batch_create)
There are two changes for this method:
get_batch_job_result (batch_status)
This method should be replaced by the following methods (method names are just draft names):
get_batch_list
Input:
Output:
This method could result in a lot of data. Maybe paging would help? In the usual case this method is only used once, and then the calling script will cache the data.
get_batch_status
Input:
Output:
This is a method that the calling script will use multiple times, and there is no need to repeat the hash-IDs unless really requested. This method could result in a lot of data. Maybe paging would help?