chore: Replace local EMR on EKS module with virtual cluster sub-module from terraform-aws-emr

[bryantbiggs]

What does this PR do?

• Replace local EMR on EKS module with virtual cluster sub-module from terraform-aws-emr
• Update EMR patterns to use EKS Blueprints addons module; align on Terraform required versions, EBS CSI IRSA
• Update variables to follow convention of description, type, default ordering

Motivation

• Removes used of local EMR on EKS sub-module and use publicly available EMR Virtual Cluster module
• Standardization

More

• Yes, I have tested the PR using my local account setup (Provide any test evidence report under Additional Notes)
• Mandatory for new blueprints. Yes, I have added a example to support my blueprint PR
• Mandatory for new blueprints. Yes, I have updated the website/docs or website/blog section for this feature
• Yes, I ran pre-commit run -a with this PR. Link for installing pre-commit locally

For Moderators

• E2E Test successfully complete before merge?

Additional Notes

• I deployed the emr-eks-ack pattern to check and validate changes

[bryantbiggs]

I started updating based on the Spark pattern but the change was getting big rather quick so I didn't carry it across all the EMR patterns (so far). Do we have a standard layout for DoEKS? I'd like to move EKS Blueprints to something along the lines of:

• main.tf - has the provider blocks, common data and locals
• eks.tf - eks configs
• add-ons.tf - add-on configs
• vpc.tf - vpc configs

Then depending on the pattern there may be more additional files such as:

• emr.tf
• ?

Which I think is mostly whats shown in DoEKS if the cluster moved to its own file.

[vara-bonthu]

Absolutely, this aligns well with our established practice within the Data on EKS repository. This folder/file structure's primary objective is to offer straightforward navigation across different implementation parts like VPC, EKS, add-ons, emr-eks, FSx-for-Lustre, etc.

This enhances code readability, leading to easier and more effective maintenance. Each section's segregation into individual files allows us to make adjustments or troubleshoot specific sectors without impacting the overall infrastructure. Additionally, it streamlines the onboarding process for newcomers, enabling them to swiftly grasp the project's structure and functionality. This setup also promotes modularity, facilitating the reuse of certain configurations other blueprints(e.g., copy and paste vpc.tf file ), potentially increasing consistency and minimizing errors.

I propose we structure it as follows, but let's discuss this internally to finalize a pattern that is beneficial for both EKS Blueprints and Data on EKS:

main.tf - This can stay as it is, containing our provider blocks, locals, and data among other things. or remove it completely. Many terraform users try to look for main.tf file in terraform blueprints or modules and they might wonder where to start for reading the code. Let's discuss this a bit whether its a good idea to remove it or not.
eks.tf - I'm in favour of shifting EKS cluster resources from main.tf to eks.tf.
addons.tf - This will carry all the EKS blueprints and data addons, same as before.
vpc.tf - This will hold our VPC configurations.
emr-eks.tf - For the EMR teams. Let's keep it as emr-eks.tf to steer clear of any confusion with the EMR service.
fsx-for-lustre.tf - This will be the module for FSx.
versions.tf - Versions
providers.tf - I don't have a strong preference on keeping this as a separate file or moving it to main.tf.
and variables.tf, outputs.tf

We can remove locals.tf and data.tf files and add these to individual files that requires these local variables and data resources.

[vara-bonthu]

LGTM 🔥

@bryantbiggs Thanks! We will try split the future PRs to individual blueprints so that we can easily review and test it.