feat(cloudfront-origins): OriginGroup supports custom originId

[vobarian]

Issue # (if applicable)

Closes #31468.

Reason for this change

OriginGroup allows users to specify a custom originId for better readability and descriptiveness compared to the auto generated IDs.

Description of changes

Adding originId to OriginGroupProps was straightforward. Unfortunately, the existing design of the Distribution binding interfaces makes some assumptions that don't model the underlying domain accurately. Specifically, while it is convenient for all origins to implement IOrigin so they can be used with any Behavior, the IOrigin interface specifies a bind method that returns an OriginBindConfig having a CfnDistribution.OriginProperty and a failoverConfig. This is not an accurate way to model origin groups, as it treats a group as a singular origin (is-a relationship) that has a failover origin. Actually, an origin group is not a singular origin, but has a primary origin and failover origin. The difference is the current model implies only 2 origin IDs, while the latter more accurate model implies 3. I would have to make a lot of breaking changes to these interfaces to fix this design, so I just added an originGroupId property to OriginBindConfig to provide a way to return the 3rd ID needed. I consider it a bit messy but could not find another way without completely redesigning the binding object model.

Additionally, the duplicate ID checking is now more complicated. Since the existing model incorrectly treats the primary origin as the originId of the group, there was already a separate originGroupId property in the BoundOrigin. I guess that was a previous workaround for the problems with the model. As a result, adding an OriginGroup requires 4 comparisons with each existing Origin (cross product of originId and originGroupId, as there is really only one ID scope and they must be unique).

Description of how you validated changes

Unit tests added in origin-group.test.ts.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

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

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[vobarian]

Exemption Request

Features must contain a change to a README file.
Features must contain a change to an integration test file and the resulting snapshot.

Just adding originId; other existing origins I checked do not document these properties in the readme and do not include customizing originId in the integration tests.

[badmintoncryer]

@vobarian Thank you for your contribution.
This modification is adding a new props, and it is necessary to execute integ test and update README.

Could you please take care of this?
If there are any issues with running the integration tests, feel free to let me know, and I’ll be happy to assist.

[godwingrs22]

Hi @vobarian, Are you still working on this PR? As a reminder, we need to add new integ test for the new property with updated Readme as suggested by @badmintoncryer.

Let me know if you need any help or have any questions.

[aws-cdk-automation]

This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 843d968
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository