-
-
Notifications
You must be signed in to change notification settings - Fork 674
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: Refactor module to use maps instead of lists #305
feat!: Refactor module to use maps instead of lists #305
Conversation
Nice! Let me know when this is ready for my review :) |
yes, sorry forgot to hit the button there 😅 - but its ready for review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm facing #289 so I gave a try to your MR.
@antonbabenko What do you think? Is this ready to be merged? |
Highly interested in this refactor too! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks great, mostly small questions, but also some thoughts about simplifying the map value (WDYT?).
|
||
rules = { | ||
cognito = { | ||
actions = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Variable structure and naming (in general) is hard.
There are multiple levels inside of the map inside of listeners
, and I am wondering if we can simplify it somehow? For example:
listeners = {
https = { # It is not obvious if this is a "type" of a listener of just any name?
# ... some common arguments like "port", "protocol", "ssl_policy"...
forward = { # "forward" is an action, but it looks like it can be also a common argument for the listener like those listed above
# omitted...
}
rules = { # is "rules" a required argument?
cognito = { # is this key "cognito" a keyword for some type of a rule?
actions = [ # a list of actions to apply in which situation?
It is pretty hard to navigate such multiple-level maps and understand what are the required arguments for the listeners, for the type of action ("forward", "weighted_forward", "fixed_response", "redirect", etc), or for something else.
Maybe we can improve it by making more granular examples to show multiple combinations of such values, too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes - any of the networking resources tend to get very gnarly with just miles of nested maps. I actually created an AppMesh module awhile ago but after seeing such deeply nested maps everywhere, I felt like that wasn't going to do any good so it never saw the light of day 😅 (see snippet below)
I think this starts getting into the specific examples/blueprints territory - a few questions for you:
- Do we want to show actual examples or just snippets in docs
- Should that be added in this PR or follow up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nested maps are, unfortunately, the best solution. We can help users by showing snippets in the docs.
Let's update README in the root module and show how to use this module "in general for ALB" and include multiple small chunks of configurations to illustrate different "actions" (forward, redirect, fixed-response, etc).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated the main README to show some examples and then I added this https://github.com/bryantbiggs/terraform-aws-alb/blob/refactor/for-each/docs/patterns.md to start collecting contributions on usage patterns from the community. I'll open an issue to signal this and see if we get an Hacktoberfest contributors to these usage patterns! (ALBs and NLBs aren't my wheelhouse so, struggling a bit in the usage pattern area here 😅 )
also, do you know whats up with the wrappers? I can't figure out why the CI keeps showing a diff, even if I manually fix it |
@antonbabenko Looks good to me. |
Waiting for this feature too! |
Any update on this PR? @antonbabenko I think the majority of the work has been done and only few tweaks are needed to push this through. I think many consumers of the module can benefit from it! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks very good (and sorry for such a long delay with the review)!
Co-authored-by: Anton Babenko <anton@antonbabenko.com>
Co-authored-by: Anton Babenko <anton@antonbabenko.com>
Almost at the finish line. Love you guys! |
9a16796
to
12bb6e3
Compare
Not sure if CI will correct itself once this is merged, but I had to manually adjust the wrappers to get it to pass CI. I'll follow up with an issue to ask for contributions to the patterns doc to collect common configuration/usage patterns to make groking the nested maps easier for folks. For now, I think we're close enough so here we go 🚀 |
@bryantbiggs I have just run the hook on this PR locally, and it behaves as on CI. Maybe you have the wrong versions of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🚀
This PR is included in version 9.0.0 🎉 |
For all following this PR, or those who may find there way here - please come help us contribute the configuration snippets that demonstrate the common usage patterns under the new v9.0 module definition. Details can be found here, thanks all! #311 |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Description
Backwards incompatible changes
target_groups
previously were defined by an array of target group definitions that were created using thecount
meta-argument. This has been replaced with a map of target group definitions that are created using thefor_each
meta-argument in order to provide better stability when adding/removing target group definitions.target_groups
no longer support multiple targets per target group. There are alternate methods to achieve similar functionality such as weighted target groups or using an autoscaling group as a target when targetting EC2 instances.listeners
, which take a map of listener definitions that are created using thefor_each
meta-argument in order to provide better stability when adding/removing listener definitions. Previously thetarget_group_index
was used to associate/reference a target group; that is now replaced withtarget_group_key
which is the key of the target group definition in thetarget_groups
map.security_group_rules
has been replaced bysecurity_group_ingress_rules
andsecurity_group_egress_rules
to align with the new underlying resources.v5.13
to support the latest features provided via the resources utilized.v1.0
Name
tag has been removed from resourcesAdded
route53_records
variableModified
enable_cross_zone_load_balancing
now defaults totrue
drop_invalid_header_fields
now defaults totrue
enable_deletion_protection
now defaults totrue
associate_web_acl
has been added to identify when a WAFv2 Web ACL should be associated with the ALB; previously this was accomplished by checking for the presence of a value passed toweb_acl_arn
which is known to cause issues when the value does not exist and is computed.See UPGRADE-9.0.md for further details
Motivation and Context
Breaking Changes
How Has This Been Tested?
examples/*
to demonstrate and validate my change(s)examples/*
projectspre-commit run -a
on my pull request