This repository has been archived by the owner on Feb 14, 2024. It is now read-only.
add stickiness support for gateway load-balancer #318
Closed
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
This pull request is related to issue #316.
The default hash algorithm may introduce issues in certain scenarios, for example for FTP connection with centralize inspection. The reason is the default 5-tuple has algorithm used by the gateway load balancer. This algorithm may load-balance across several firewall causing the other end to drop traffic as different connections related to the same session use different public IPs.
This pull request add a variable to trace the desire of the user to change the default hash algorithm. aws/provider introduce several options from version 4.38 and above. Allowing the users to select with a granularity the hash algorithm among three possible options.
The rational behind the change is that the assignment of a value to that variable will generate the dynamic block related to stickiness in the gateway load balancer.
Motivation and Context
This change is needed because in our production environment we found the FTP issues shared in #316 and was resolved changing the hash algorithm.
How Has This Been Tested?
This has been tested in a development environment and then in production.
Development testing was done with one test:
Production testing was done with two test:
Test 1: Verify that the current environment is not change in case of the introduction of the changes. This is doing the changes to the cade but leave default value for the new variable. This is to make sure that this change are not harmfull to current deployed environments that do not need this value to be set.
Test 2: Assign a value to the variable in the "envmodules" of terragrunt in order to make effective the change of hash algorithm. In this case the change is detected and the hash algorithm is changed properly.
Is worth noting that the possible values of hash algorithm has change from aws/provides 4.37 and 4.38, giving more options from 4.38 and above. I have not change the minimum release version of the provider but is worth noting that our environment runs 4.57 to make use of the new values.
As far as we have reviewed this change is quite an add-on in the sense that it does not impact older deployment and is just giving the user the option to set the hash algorithm in case necesary.
Screenshots (if appropriate)
Types of changes
Add a variable to the gwlb module in order to select hash algorithm option available in the aws/provider.
In case the variable is set a dynamic "stickiness" module is added.
Checklist
NOTE: I have read the contributing but was unable to rebase with "upstream dev", so I rebase with main. In case this is wrong I can change that to the proper branch.