You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: this is not really a new feature but I wanted to create an issue for this work so we can track it.
The elbv2 logic around comparing listeners and listener rules is quite complex, which is unsurprising as the AWS logic is also complex. However, as it is currently written it's very difficult to understand what each of these comparisons is doing. In some cases, methods have been updated over time to fix bugs but the method names and docstrings haven't changed. This makes it prone to errors (see #1877, #1284) and difficult to review new bugfixes. I propose we refactor this with an eye to making our code easier to understand, in particular:
Documenting what is the AWS logic/requirements we are trying to enforce when creating or modifying a listener/rule (note that the requirements for creating vs. modifying are not the same).
Ensuring that methods/functions have type hints so it's clear what a given method returns.
Adding documentation to each method to clarify what it does.
Thinking about whether we can break any of these methods down into smaller, more discrete comparison methods with simpler tests.
Ensuring we have unit tests covering all the logic we are trying to enforce.
Issue Type
Feature Idea
Component Name
module_utils/elbv2
Additional Information
Refactoring this code would make it easier to maintain, as it is currently challenging to understand and modify.
Code of Conduct
I agree to follow the Ansible Code of Conduct
The text was updated successfully, but these errors were encountered:
Summary
Note: this is not really a new feature but I wanted to create an issue for this work so we can track it.
The elbv2 logic around comparing listeners and listener rules is quite complex, which is unsurprising as the AWS logic is also complex. However, as it is currently written it's very difficult to understand what each of these comparisons is doing. In some cases, methods have been updated over time to fix bugs but the method names and docstrings haven't changed. This makes it prone to errors (see #1877, #1284) and difficult to review new bugfixes. I propose we refactor this with an eye to making our code easier to understand, in particular:
Issue Type
Feature Idea
Component Name
module_utils/elbv2
Additional Information
Refactoring this code would make it easier to maintain, as it is currently challenging to understand and modify.
Code of Conduct
The text was updated successfully, but these errors were encountered: