feature: allow setting the default bucket in Session

[knakad]

Issue: #1165

Description of changes: Session now allows default bucket name to be passed in. Particularly useful in controlled environment where new buckets cannot be created.

Testing done: New tests added to validate expected custom bucket

Merge Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.

• I have read the CONTRIBUTING doc
• I used the commit message format described in CONTRIBUTING
• I have used the regional endpoint when creating S3 and/or STS clients (if appropriate)
• I have added tests that prove my fix is effective or that my feature works (if appropriate)
• I have checked that my tests are not configured for a specific region or account (if appropriate)
• I have updated any necessary documentation, including READMEs and API docs (if appropriate)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[sagemaker-bot]

AWS CodeBuild CI Report

• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[sagemaker-bot]

AWS CodeBuild CI Report

• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[sagemaker-bot]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[sagemaker-bot]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[sagemaker-bot]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[sagemaker-bot]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[sagemaker-bot]

AWS CodeBuild CI Report

• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[sagemaker-bot]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[andremoeller]

IMO: since this functionality lives in the parent Processor and propagates down to child classes, the test should use the Processor class rather than SKLearnProcessor. (If we validate using Processor, we validate for all child classes, but if we validate using SKLearnProcessor, we don't validate for parent classes.)

[knakad]

I see it the other way around.
I prefer to use the implementation in this case (SKLearnProcessor), because it allows us to validate the superclass inherited methods (normalization of inputs) AS WELL as the custom implementation logic (automatic code upload).

[andremoeller]

^ ah, I realize I should've said ScriptProcessor, not Processor -- if another child class of ScriptProcessor is added, and if the integ tests use ScriptProcessor, automatic code upload would be tested for that new class by dint of it being tested with ScriptProcessor. (For example: what if SKLearnProcessor has some code added to it that lets this test pass just for SKLearnProcessor?)