[PCUI] Support On-Demand Capacity Reservations and Capacity Blocks for PCUI

[hehe7318]

Description

feat: Support ODCR(On-Demand Capacity Reservations) and CB(Capacity Blocks) for PCUI

Changes

• Added CapacityReservationTarget select component at the compute resource level, allowing users to choose between CapacityReservationId, CapacityReservationResourceGroupArn, or none.
• Implemented dynamic placeholders to guide users on the required inputs for CapacityReservationId and CapacityReservationResourceGroupArn.
• Introduced CAPACITY_BLOCK as a new purchase type option in the UI.
• Automatically hide the Allocation Strategy selection when CAPACITY_BLOCK is selected, following the expected behavior in ParallelCluster.
• Implemented logic to automatically hide the instance type selection and exclude the Instances section in the YAML when CapacityReservationId is selected.
• Made the Instances property of MultiInstanceComputeResource optional.
• Updated the mechanism in queues.mapper.ts to resolve the conversion conflict.
• Added CapacityReservationTarget in queue types.
• Updated validateComputeResources to adapt to the new changes, allowing Instances to be empty if CapacityReservationId is selected.
• Added info panel for Capacity Reservation and Capacity Block, included documentation links and note on instance type usage.

Note:

ParallelCluster supports CapacityReservationTarget at both the queue and compute resource levels. However, the official documentation (Launch Instances into On-Demand Capacity Reservations (ODCR) - ParallelCluster, Launch Instances Using Capacity Blocks - ParallelCluster) recommends managing CapacityReservationTarget at the compute resource level. If CapacityReservationTarget is specified at both the queue and compute resource levels, the compute resource level option overrides the queue level option.

Implementing CapacityReservationTarget at the queue level is unnecessary, as it adds complexity and requires significant refactoring due to internal PCUI mechanisms that conflict with this implementation. The decision not to implement CapacityReservationTarget at the queue level does not impact customers, given that control at the compute resource level aligns with best practices and recommendations.

How Has This Been Tested?

Manually test passed, and worked as expected.

References

Launch Instances into On-Demand Capacity Reservations (ODCR) - ParallelCluster
Launch Instances Using Capacity Blocks - ParallelCluster
aws parallelcluster Scheduling section

PR Quality Checklist

• I added tests to new or existing code
• I removed hardcoded strings and used react-i18next library (useTranslation hook and/or Trans component), see an example here
• I made sure no sensitive info gets logged at any time in the codebase (see here) (e.g. no user info or details, no stacktraces, etc.)
• I made sure that any GitHub issue solved by this PR is correctly linked
• I checked that infrastructure/update_infrastructure.sh runs without any error
• I checked that npm run build builds without any error
• I checked that clusters are listed correctly
• I checked that a new cluster can be created (config is produced and dry run passes)
• I checked that login and logout work as expected

In order to increase the likelihood of your contribution being accepted, please make sure you have read both the Contributing Guidelines and the Project Guidelines

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[himani2411]

I dont think this should be the description! This should tell them what to do rather than ask them to Learn

Other wise the whole CR LGTM

[hehe7318]

Fixed.