fix: fix instance_type assignment logic

[benfriebe]

Issue #, if available:
4666 - aws/amazon-sagemaker-examples#4666

Description of changes:
In this code change, the logic for assigning the instance_type variable has been improved by using the Python or operator instead of a ternary conditional expression.

The original code:

instance_type = model_deploy_kwargs.instance_type if training_instance_type is None else None

This line checks if training_instance_type is None. If it is None, it assigns model_deploy_kwargs.instance_type to instance_type. Otherwise, it assigns None to instance_type, which seems counterintuitive and results in it ignoring a passed in instance_type if a training_instance_type also exists.

The new code:

instance_type = model_deploy_kwargs.instance_type or training_instance_type

This line uses the or operator to assign the value of model_deploy_kwargs.instance_type to instance_type if it is a "truthy" value (i.e., not None, 0, False, or an empty collection). If model_deploy_kwargs.instance_type is a "falsy" value (i.e., None, 0, False, or an empty collection), it will assign the value of training_instance_type to instance_type.

This change improves the logic by ensuring that instance_type is assigned a non-None value if either model_deploy_kwargs.instance_type or training_instance_type has a valid value.

Testing done:
No new tests added, ran with existing unit tests locally and results remain the same.

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.

General

• I have read the CONTRIBUTING doc
• I certify that the changes I am introducing will be backward compatible, and I have discussed concerns about this, if any, with the Python SDK team
• I used the commit message format described in CONTRIBUTING
• I have passed the region in to all S3 and STS clients that I've initialized as part of this change.
• I have updated any necessary documentation, including READMEs and API docs (if appropriate)

Tests

• I have added tests that prove my fix is effective or that my feature works (if appropriate)
• I have added unit and/or integration tests as appropriate to ensure backward compatibility of the changes
• I have checked that my tests are not configured for a specific region or account (if appropriate)
• I have used unique_name_from_base to create resource names in integ tests (if appropriate)

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

[JGuinegagne]

This change does not look correct, let's hold till SME is back in office please.

[JGuinegagne]

This change doesn't look right, the attribute is referring to the hosting instance type, it should not be passed a training instance type.

I think it should just be something like:

# if passed an instance type, use it
deploy_instance_type = instance_type

# otherwise, if passed a training instance, derive from training instance
if not instance_type and training_instance_type
  deploy_instance_type = instance_types.retrieve_default(
    model_id,
    model_version,
    training_instance_type=training_instance_type
  )
else:
  deploy_instance_type = model_deploy_kwargs.instance_type

Can we wait for SME @evakravi to look at this code change before merging?

[benfriebe]

I based the above change on the commit where it was introduced, which also added:

training_instance_type (str): In the case of a model fine-tuned on SageMaker, the training
            instance type used for the training job that produced the fine-tuned weights.
            Optionally supply this to get a inference instance type conditioned
            on the training instance, to ensure compatability of training artifact to inference
            instance. (Default: None).

Which I now notice should also:

- compatability
+ compatibility 

Happy to wait for @evakravi to be back in office to discuss what is the best approach here.

[evakravi]

@JGuinegagne The logic you have looks right. But let's definitely add unit tests so there's no doubt that this fixes the problem at hand.