docs: Add note for next breaking change to remove load_balancers
and target_group_arns
from use
#253
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
load_balancers
andtarget_group_arns
from useMotivation and Context
aws_autoscaling_traffic_source_attachment
in feat: Add support for traffic source attachment #248, this has introduced a second point of control for load balancer attachment which started showing up in diffs on the autoscaling group resource. In fix: Ignore changes toload_balancers
andtarget_group_arns
#252 we have suppressed this diff by ignoring all changes toload_balancers
andtarget_group_arns
used directly on the autoscaling group resource. In hindsight, this was not an ideal route for users. Going forward, at the next breaking change we should remove the use ofload_balancers
andtarget_group_arns
and strictly use thetraffic_source_*
arguments. Theaws_autoscaling_traffic_source_attachment
is more flexible and supports more resources than what the ASG resource does directly today. You can think of the similar lifecycle that security groups and security group rules have gone through (first rules were set on the group resource, later a separate resource was added for rules only, and then later a 3rd more explicit rule resource was added - all to differentiate between the different lifecycles of the resources and their behaviors)Breaking Changes
How Has This Been Tested?
examples/*
to demonstrate and validate my change(s)examples/*
projectspre-commit run -a
on my pull request