-
Notifications
You must be signed in to change notification settings - Fork 340
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
Add more detailed listeners, rules, actions to AWS ELBv2 load balancers. #1168
base: master
Are you sure you want to change the base?
Add more detailed listeners, rules, actions to AWS ELBv2 load balancers. #1168
Conversation
Record rules, conditions and actions in the form (ELBV2Listener)-[ELBV2_LISTENER_RULE]-(ELBV2Action). This allows us to analyze the path of requests that are intelligently routed based on HTTP request parameters by AWS Application Load Balancers.
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.
This is a very cool PR and I'm looking forward to having this visibility. I mentioned this a while ago in a meeting but I'd like to have new plugins use the new data model. This way you get automatic cleanup jobs and it's less error prone to create new relationships.
Adopting the new data model means that the transform()
functions will be doing more work to adjust the data into a workable shape for the querybuilder. One adjustment that'll need to happen is with things like this:
MATCH (rule:ELBV2Rule{id: $RuleId})-[ATTACHED_TO]->(listener:ELBV2Listener)
... attach something to the listener ...
Here, we match on a Rule and then attach more data to the attached listener. To adapt to the new data model, we'd have to return an ID for the attached listener. This is a bit hard to explain in a comment but let me know when you get to this point and we can have a call. Let me know if you can't work on this and I'll see how far I can get adapting it. Might be easiest to do one new data type at a type.
Sorry for the slowness!
MATCH (rule:ELBV2Rule{id: $RuleId})-[ATTACHED_TO]->(listener:ELBV2Listener) | ||
WITH listener, rule | ||
UNWIND $Actions as action | ||
MERGE (listener)-[rr:ELBV2_LISTENER_RULE]->(actionNode:ELBV2Action:""" + type + """{id: action.id}) |
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.
Rather than keep the same information in two places - in the ELBV2Rule and this relationship - I'd rather just keep it in one place and prefer keeping the attributes in the ELBV2Rule node.
There is also an ATTACHED_TO
relationship between ELBV2Rule
s and ELBV2Listeners
. I think having both ATTACHED_TO
and ELBV2_LISTENER_RULE
is a bit crowded so we should decide on keeping just one.
Record rules, conditions and actions in the form (ELBV2Listener)-[ELBV2_LISTENER_RULE]-(ELBV2Action). This allows us to analyze the path of requests that are intelligently routed based on HTTP request parameters by AWS Application Load Balancers.