Feature/describe cluster

[mohamedzeidan2021]

Detailed reason why we are adding this command: https://tiny.amazon.com/jje9mvzv/quipLs4V

What's changing and why?

Added a new hyp describe cluster command to provide info about hp clusters.

• this command is added to fill a gap in the CLI funcionality.
• hyp describe cluster-stack existed, but there was not equivalent command to describe the cluster resources directly
• This command will be outputted to the user to be used when they delete cluster's with the future hyp delete cluster cmd

Before/After UX

Before:

Users can previously only use hyp list-cluster to get information about their clusters.
The hyp list-cluster cmd outputs

{
        "Cluster": "ml-cluster-integ-test",
        "Instances": [
            {
                "InstanceType": "ml.c5.2xlarge",
                "TotalNodes": 30,
                "AcceleratorDevicesAvailable": "N/A",
                "NodeHealthStatus=Schedulable": 30,
                "DeepHealthCheckStatus=Passed": "N/A"
            },
            {
                "InstanceType": "ml.g5.8xlarge",
                "TotalNodes": 13,
                "AcceleratorDevicesAvailable": 13,
                "NodeHealthStatus=Schedulable": 13,
                "DeepHealthCheckStatus=Passed": 13
            },
            {
                "InstanceType": "ml.g5.2xlarge",
                "TotalNodes": 1,
                "AcceleratorDevicesAvailable": 1,
                "NodeHealthStatus=Schedulable": 1,
                "DeepHealthCheckStatus=Passed": "N/A"
            }
        ]
    }

After:

Now if users wanted details on a specific cluster, they can run:

$ hyp describe cluster hyperpod-cluster
📋 Cluster Details for: hyperpod-cluster
Status: InService
 ClusterArn               | arn:aws:sagemaker:us-east-2:123456789012:cluster/hyperpod-cluster
 ClusterName              | hyperpod-cluster
 ClusterStatus            | InService
 CreationTime             | 2025-09-23 14:35:38
 InstanceGroups           | [
                          |   {
                          |     "CurrentCount": 1,
                          |     "TargetCount": 1,
                          |     "InstanceGroupName": "controller-group",
                          |     "InstanceType": "ml.t3.medium",
                          |     "LifeCycleConfig": {
                          |       "SourceS3Uri": "s3://my-hyperpod-bucket",
                          |       "OnCreate": "on_create.sh"
                          |     },
                          |     "ExecutionRole": "arn:aws:iam::123456789012:role/HyperPodExecutionRole",
                          |     "ThreadsPerCore": 1,
                          |     "InstanceStorageConfigs": [
                          |       {
                          |         "EbsVolumeConfig": {
                          |           "VolumeSizeInGB": 500
                          |         }
                          |       }
                          |     ],
                          |     "Status": "InService"
                          |   }
                          | ]
 VpcConfig                | {
                          |   "SecurityGroupIds": ["sg-1234567890abcdef0"],
                          |   "Subnets": ["subnet-1234567890abcdef0"]
                          | }
 Orchestrator             | {
                          |   "Eks": {
                          |     "ClusterArn": "arn:aws:eks:us-east-2:123456789012:cluster/eks-cluster"
                          |   }
                          | }
 NodeRecovery             | Automatic

How was this change tested?

Tested the command manually with different scenarios including cluster names, invalid cluster names, and different aws regions.

Are unit tests added?

Yes, added 7 test cases

• happy case with successful cluster output
• region flag testing
• unknown cluster name
• access denied mock scenarios
• generic aws api errors
• debug flag functionality
• empty response handling

Are integration tests added?

No

Reviewer Guidelines

‼️ Merge Requirements: PRs with failing integration tests cannot be merged without justification.

One of the following must be true:

• All automated PR checks pass
• Failed tests include local run results/screenshots proving they work
• Changes are documentation-only