feat: Make DistributedConfig Extensible

[benieric]

Issue #, if available:

Description of changes:

• This change is being introduced to update the DistributedConfig class to be more extensible

Base Class Update:

class DistributedConfig(BaseModel, ABC):
    @property
    @abstractmethod
    def driver_dir(self) -> str:
        pass
    
    @property
    @abstractmethod
    def driver_script(self) -> str:
        pass

Customer Usage Example:

# Create Subclass
class CustomDriver(DistributedConfig):
    process_count_per_node: Optional[int] = None
	driver_args: Optional[List[str]] = None
    
    @property
    def driver_dir(self) -> str:
        return "drivers" 
    
    @property
    def driver_script(self) -> str:
        return "custom_driver.py"
        

# Instantiate CustomDriver
custom_driver = CustomDriver(
    process_count_per_node=2
)

source_code = SourceCode(
    source_dir="code",
    entry_script="train.py"
)

model_trainer = ModelTrainer(
    source_code=source_code,
    distributed=custom_driver
)

How to create acustom_driver.py:

import json
import os
import subprocess


def main():
    # Referencing custom driver config properties
    driver_config = json.loads(os.environ["SM_DISTRIBUTED_CONFIG"])
	process_count_per_node = driver_config["process_count_per_node"]
    
    # Because subclassing allows for user to setup custom properties
    # they can configure their driver config to accept a list of driver args
    # which would be seperate from the hyperparameters
    driver_args = driver_config["driver_args"]
    
    
    # Referencing hyperparamter
    hps = json.loads(os.enviorn["SM_HPS"])
    
    # Referencing their entry script defined in SourceCode(entry_script=...)
    entry_script = os.enviorn["SM_ENTRY_SCRIPT"]
    
    # Utilize existing env vars for other parameters
    host_count = os.enviorn["SM_HOST_COUNT"]
	master_addr = os.enviorn["SM_MASTER_ADDR"]
	master_port = os.enviorn["SM_MASTER_PORT"]
	current_node_rank = os.environ["SM_CURRENT_HOST_RANK"]
    
    # Reference path to code defined under SourceCode(source_dir=...)
    source_dir = os.enviorn["SM_SOURCE_DIR"]
    
    # Reference path to code defined under CustomDriver(driver_dir=...)
    driver_dir = os.enviorn["SM_DRIVER_DIR"]
    
    command = [
        "deepspeed",
        f"--num_nodes={host_count}"
        f"--nproc_per_node={process_count_per_node}",
        driver_args,
        entry_script,
    ]
 
    subprocess.run(command, check=True)
 
if __name__ == "__main__":
    main()

What changes in the container?

In order to prevent conflicts with user provided code in the driver_dir and sdk scripts, the directory structure inside the container will change to be like below.

Before:

/opt/ml/input/data
                |--code/ # path for code defined in SourceCode(source_dir=...)
                    
                |--sm_drivers/ # path to all sagemaker drivers, and extra code that sdk packages
                    |--scripts/
                        |-- enviornment.py 
                    |-- utility.py
                    |-- mpi_driver.py
                    |-- torchrun_driver.py
                    |-- basic_script_driver.py

After:

/opt/ml/input/data
                |--code/ # path for code defined in SourceCode(source_dir=...)
                
                |--sm_drivers/
                    |--scripts/
                            |-- enviornment.py 
                    |--drivers/ # path to code defined in DistributedConfig(driver_dri=...)
                            |-- mpi_driver.py
                            |-- torchrun_driver.py
                            |-- basic_script_driver.py
                    |--common/
                       	|-- utility.py

What env vars are being added?

• os.environ["SM_ENTRY_SCRIPT"] - points to entry script
• os.environ["SM_DISTRIBUTED_CONFIG"] - points to a json dump of the DistributedConfig class
• os.environ["SM_SOURCE_DIR"] - points to the "/opt/ml/input/data/code"
• os.environ["SM_DRIVER_DIR"] - points to "/opt/ml/input/data/sm_drivers/drivers"

Testing done:

• Tested changes are not breaking existing integs, new integs in progress

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)
• If adding any dependency in requirements.txt files, I have spell checked and ensured they exist in PyPi

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