You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Previously, we created unify TrainingClient to give user an ability to create Training Operator Job using single client.
Currently, in our SDK we have mix of different APIs.
For example, to create training job we use job-specific APIs (e.g. create_tfjob), but to get training job logs we use single API despite on job kind (e.g. get_job_logs).
Some of the APIs require job_kind to bet set (e.g. get_job_conditions).
That causes confusions for our users, especially for those who work with single type of Job (e.g. PyTorchJob).
Also, as I mentioned here: #1863 (comment), to get Job events in get_job_logs API, we need to introduce job_kind argument for this API.
Therefore, I propose to make all of these APIs consistent as follows:
All CRUD APIs won't be job-specific. For example: create_job, create_job_from_func, delete_job, update_job, etc.
When it is required, we will do appropriate logic depending on job_kind. For example, create the required Training replicas in create_job_from_func API.
job_kind argument can be overridden for every API. So user can use single TrainingClient to create different Training Jobs.
I believe, that should simplify experience of our API usage.
Previously, we created unify
TrainingClient
to give user an ability to create Training Operator Job using single client.Currently, in our SDK we have mix of different APIs.
For example, to create training job we use job-specific APIs (e.g.
create_tfjob
), but to get training job logs we use single API despite on job kind (e.g.get_job_logs
).Some of the APIs require
job_kind
to bet set (e.g.get_job_conditions
).That causes confusions for our users, especially for those who work with single type of Job (e.g. PyTorchJob).
Also, as I mentioned here: #1863 (comment), to get Job events in
get_job_logs
API, we need to introducejob_kind
argument for this API.Therefore, I propose to make all of these APIs consistent as follows:
job_kind
, argument to ourTrainingClient
. Similar to ournamespace
parameter for Katib Client. Thanks to @droctothorpe for this idea!create_job
,create_job_from_func
,delete_job
,update_job
, etc.job_kind
. For example, create the required Training replicas increate_job_from_func
API.job_kind
argument can be overridden for every API. So user can use singleTrainingClient
to create different Training Jobs.I believe, that should simplify experience of our API usage.
What do you think about this @kubeflow/wg-training-leads @tenzen-y @kuizhiqing @yaobaiwei @zw0610 ?
The text was updated successfully, but these errors were encountered: