Skip to content
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

Conversation

willoak84
Copy link

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:

  • Test 1: deploying a full environment from zero with the suggested changes, allowing us to confirm that the hash algorithm can be set properly via terraform.

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.

  • New feature (non-breaking change which adds functionality)

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.

  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes if appropriate.
  • All new and existing tests passed.

@willoak84 willoak84 requested a review from a team as a code owner June 5, 2023 15:09
@welcome-to-palo-alto-networks
Copy link

🎉 Thanks for opening this pull request! We really appreciate contributors like you! 🙌

@willoak84
Copy link
Author

I close this pull request as code has been updated on #317

@willoak84 willoak84 closed this Jun 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant