docs: add usage documentation for TrainerClient options#405
docs: add usage documentation for TrainerClient options#405Harshithavigna wants to merge 1 commit intokubeflow:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
🎉 Welcome to the Kubeflow SDK! 🎉 Thanks for opening your first PR! We're happy to have you as part of our community 🚀 Here's what happens next:
Join the community:
Feel free to ask questions in the comments if you need any help or clarification! |
There was a problem hiding this comment.
Pull request overview
This PR adds documentation explaining how to use the options parameter with TrainerClient.train() to customize training job configurations. It includes an explanation of the feature and provides a usage example to help users understand backend-specific configuration options.
Changes:
- Adds a new section "Using options with TrainerClient" in the options reference documentation
- Provides an explanation of the
optionsparameter and its purpose - Includes a code example demonstrating how to pass options to
client.train()
| job_id = client.train( | ||
| trainer=CustomTrainer(func=train_fn), | ||
| options={ | ||
| "epochs": 10, | ||
| "batch_size": 32 | ||
| } | ||
| ) |
There was a problem hiding this comment.
The example shows options as a dictionary with {"epochs": 10, "batch_size": 32}, but the options parameter should be a list of option objects (e.g., [Name("custom-name"), Labels({...})]). According to the TrainerClient API signature and the options module design, options must be objects from kubeflow.trainer.options that can be called to modify the job specification. The current example misleads users about the correct API usage.
| The ``options`` dictionary can include different parameters depending on the backend | ||
| and runtime configuration. No newline at end of file |
There was a problem hiding this comment.
The description states "options dictionary" and refers to "different parameters depending on the backend", but it should clarify that options is a list of option objects, and which specific option types are available for each backend (e.g., Name, Labels, Annotations, TrainerCommand, TrainerArgs for Kubernetes, and Name for other backends).
What this PR does / why we need it:
This PR adds documentation for using
optionsin TrainerClient.It includes example usage and improves clarity for users working with training configurations.
Which issue(s) this PR fixes:
Fixes #388
Checklist: