-
Notifications
You must be signed in to change notification settings - Fork 1.2k
[Request] accept logs param in .attach() #1405
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Additionally, it looks like simply passing |
Thanks for the feature request. We're actually thinking about going a step further, and separating out the logs from estimator.attach("job-name")
estimator.logs()
# another scenario
estimator.fit(wait=False)
estimator.logs() where |
Confirming the v2 separation seems to have satisfied the original request - thanks all! |
Is your feature request related to a problem? Please describe.
Training job logs can be significantly long, and are sometimes (but not always) useful to surface when waiting on a job.
_TrainingJob.wait()
supports thelogs
parameter to give users control over this.EstimatorBase.attach()
calls.wait()
, but doesn't accept and pass through alogs
parameter: Meaning users are stuck with log pollution and potential performance degradation.Describe the solution you'd like
.attach()
should support and pass through kwargs for.wait()
, with same default behaviours as the underlying.wait()
.Describe alternatives you've considered
Could hard-wire
attach()
to a different log status e.g.wait(logs="None")
on the basis that after a training job has been completed, we don't need to re-present its logs... But this is an assumption that might be incompatible with other workflows.There's currently only one argument for
wait()
- the subject of this request... But in generalattach()
makes multiple SageMaker API calls with potentially many arguments - soattach()
arguments should probably be explicitly defined and fed through, rather than relying on**kwargs
.Additional context
Example use case: Lambda function in a Step Functions pipeline to deploy a model from a known good training job name, via the SageMaker SDK, without polluting the Lambda logs.
The text was updated successfully, but these errors were encountered: