Add emr_cluster, emr_instance_fleet, emr_instance_group

[sanhaKimVics]

Adding emr_cluster, emr_instance_fleet, emr_instance_group resource.

I have:

• Read and followed Crossplane's [contribution process].
• Run make reviewable to ensure this PR is ready for review.
• Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

Manually tested

1. emr_cluster

2. emr_instance_fleet, emr_instance_group

Current issue with emr_cluster

While I was doing uptest e2e test with the cluster example, I faced this error after successful creation.

 logger.go:42: 16:20:42 | case/0-apply |       message: 'observe failed: cannot convert the singleton lists in the observed
    logger.go:42: 16:20:42 | case/0-apply |         state value map into embedded objects: failed to convert between Crossplane
    logger.go:42: 16:20:42 | case/0-apply |         and Terraform layers in mode "fromTerraform": cannot expand wildcards for
    logger.go:42: 16:20:42 | case/0-apply |         the field path expression master_instance_fleet[*].launch_specifications:
    logger.go:42: 16:20:42 | case/0-apply |         cannot expand wildcards for segments: "master_instance_fleet[*].launch_specifications":
    logger.go:42: 16:20:42 | case/0-apply |         wildcard field "master_instance_fleet" is not found in the path

[jeanduplessis]

/test-examples="examples/emr/v1beta1/cluster.yaml,examples/emr/v1beta1/instancefleet.yaml,examples/emr/v1beta1/instancegroup.yaml"

[turkenf]

Many thanks, @sanhaKimVics 🙌 I will take a look at in detail next week.

[turkenf]

/test-examples="examples/emr/v1beta1/instancefleet.yaml"

[turkenf]

/test-examples="examples/emr/v1beta1/instancegroup.yaml"

[turkenf]

Thank you for your efforts @sanhaKimVics, I left some initial comments for you to consider.

[sanhaKimVics]

 logger.go:42: 16:20:42 | case/0-apply |       message: 'observe failed: cannot convert the singleton lists in the observed
    logger.go:42: 16:20:42 | case/0-apply |         state value map into embedded objects: failed to convert between Crossplane
    logger.go:42: 16:20:42 | case/0-apply |         and Terraform layers in mode "fromTerraform": cannot expand wildcards for
    logger.go:42: 16:20:42 | case/0-apply |         the field path expression master_instance_fleet[*].launch_specifications:
    logger.go:42: 16:20:42 | case/0-apply |         cannot expand wildcards for segments: "master_instance_fleet[*].launch_specifications":
    logger.go:42: 16:20:42 | case/0-apply |         wildcard field "master_instance_fleet" is not found in the path

@turkenf
After successfully creating the cluster with Uptest, I kept getting the same error as before, so I couldn't pass the local automated test.

Any help to resolve this would be appreciated.

[sanhaKimVics]

/test-examples="examples/emr/v1beta1/cluster.yaml"

[turkenf]

Hi @sanhaKimVics, thank you for your patience here. Are you still interested in moving this PR forward? If so, please rebase your PR to the main, run make generate, and test the resources again. If you still get errors please let us know.

[sanhaKimVics]

Hi @sanhaKimVics, thank you for your patience here. Are you still interested in moving this PR forward? If so, please rebase your PR to the main, run make generate, and test the resources again. If you still get errors please let us know.

Sure I'll rebase and do the test again thank you!

[mergenci]

Suggested change

	}
	})
	}
	config.MoveToStatus(r.TerraformResource, "master_instance_fleet")
	})

I'm replying to a runtime error reported in the Crossplane community Slack thread:

observe failed: cannot convert the singleton lists in the observed state value map into embedded objects: failed to convert between Crossplane and Terraform layers in mode "fromTerraform": cannot expand wildcards for the field path expression master_instance_fleet[*].launch_specifications: cannot expand wildcards for segments: "master_instance_fleet[*].launch_specifications": wildcard field "master_instance_fleet" is not found in the path

I don't have much experience with resource configuration, but moving master_instance_fleet to status might be worth trying. Even if doing so wasn't not the right way to configure the resource, the result might tell more about how to address the issue.