fix(ecs): default ecsmanagedtags and propagatetags to be undefined

[piradeepk]

EcsManagedTags require customers to have opted in to using long arns, but for customer who do not have long arns, it will fail their build.

PR: #3420 set enabledECSManagedTags to true by default and set propagateTags to the Service. Updated the defaults to be undefined for propagateTags and false for enableECSManagedTags. If a user wishes to enable either, they can manually override the properties.

Addresses: #3844

Testing:

• Created a FargateService with the code currently in master (ECSManagedTags set to true by default) - Able to reproduce the error
• Made the changes to default ECSManagedTags to false.
• Created the same FargateService with the changes - Able to successfully create a stack

Outputs:
aws-ecs-integ.L3LoadBalancerDNS####### = #########.us-west-2.elb.amazonaws.com
Stack ARN:
arn:aws:cloudformation:us-west-2:############:stack/aws-ecs-integ/#########-####-####-####-#########

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

[mergify]

Pull Request Checklist

• Testing

• Unit test added (prefer to add a new test rather than modify existing tests)
• CLI change? Re-run/add CLI integration tests

• Documentation

• Inline docs: make sure all public APIs are documented (copy & paste from official AWS docs)
• README: update module README
• Design: for significant features, follow the design process

• Title uses the format type(scope): text

• Type: fix, feat, refactor go into CHANGELOG, chore is hidden
• Scope: name of the module without the aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
• Style: use all lower-case, do not end with a period

• Description

• Rationale: describe rationale of change and approach taken
• Issues: Indicate issues fixed via: fixes #xxx or closes #xxx
• Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>

• Sensitive Modules (requires 2 PR approvers)

• IAM document library (in @aws-cdk/aws-iam)
• EC2 security groups and ACLs (in @aws-cdk/aws-ec2)
• Grant APIs (if not based on official documentation with a reference)

[mergify]

Pull Request Checklist

• Testing

• Unit test added (prefer to add a new test rather than modify existing tests)
• CLI change? Re-run/add CLI integration tests

• Documentation

• Inline docs: make sure all public APIs are documented (copy & paste from official AWS docs)
• README: update module README
• Design: for significant features, follow the design process

• Title uses the format type(scope): text

• Type: fix, feat, refactor go into CHANGELOG, chore is hidden
• Scope: name of the module without the aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
• Style: use all lower-case, do not end with a period

• Description

• Rationale: describe rationale of change and approach taken
• Issues: Indicate issues fixed via: fixes #xxx or closes #xxx
• Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>

• Sensitive Modules (requires 2 PR approvers)

• IAM document library (in @aws-cdk/aws-iam)
• EC2 security groups and ACLs (in @aws-cdk/aws-ec2)
• Grant APIs (if not based on official documentation with a reference)

[mergify]

Codebuild (Continuous Integration) build failed for current commits. Please check log and resolve before PR is merged.

[allisaurus]

LGTM pending build + tests pass

Pull request has been modified.

[allisaurus]

LGTM pending build + tests pass

Pull request has been modified.

[shivlaks]

Thanks for making this change! I think these defaults are more user friendly at this time.

Have you considered maybe adding a warning as a metadata entry to the ConstructNode to guide customers towards opting into using longer arns? That might be a friendlier way to guide them and make them aware that an enforcement date is looming.

[piradeepk]

Thanks for making this change! I think these defaults are more user friendly at this time.

Have you considered maybe adding a warning as a metadata entry to the ConstructNode to guide customers towards opting into using longer arns? That might be a friendlier way to guide them and make them aware that an enforcement date is looming.

I definitely agree, but I'm leaning towards doing this in a separate PR once we have a date. Want to unblock users who are having this issue and get this into the next release.

[mergify]

Thank you for contributing! Your pull request is now being automatically merged.

[mergify]

Thanks so much for taking the time to contribute to the AWS CDK ❤️

We will shortly assign someone to review this pull request and help get it
merged. In the meantime, please take a minute to make sure you follow this
checklist:

• PR title type(scope): text
  • type: fix, feat, refactor go into CHANGELOG, chore is hidden
  • scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
  • text: use all lower-case, do not end with a period, do not include issue refs
• PR Description
  • Rationale: describe rationale of change and approach taken
  • Issues: indicate issues fixed via: fixes #xxx or closes #xxx
  • Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
• Testing
  • Unit test added. Prefer to add a new test rather than modify existing tests
  • CLI or init templates change? Re-run/add CLI integration tests
• Documentation
  • README: update module README to describe new features
  • API docs: public APIs must be documented. Copy from official AWS docs when possible
  • Design: for significant features, follow design process