Cloud Custodian
Replies: 6 comments 2 replies
-
|
its worthwhile to look at the resources.json output when you don't have a filter. In this case the Listeners attribute is not present at all in the returned resource. In gitter, you referenced its an empty array but thats not the case they key doesn't exist, so you can use the following to assert that. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks again for the response @kapilt . Correct. When I run with It matches on all my ALBs. When I look at the resources.json, it shows matched on the filter and I don't see anything in the json. So this brings me back to the original question in the first issue I opened. Is there a way to match on an app-elb that does not have any target groups/listeners attached? Perhaps that is simply not a capability today? ( Since neither of the suggested methods seem to work since there is "Listeners" in the resource.json) |
Beta Was this translation helpful? Give feedback.
-
|
Hi Kapil. Any suggestions on if this capability should work today? I'm not on an app-elb, |
Beta Was this translation helpful? Give feedback.
-
|
I am facing this same issue. Do we know if this is a bug or weird behavior in how the app-elb is constructed? I tried digging into the code, but I don't quite understand how the nesting works between the |
Beta Was this translation helpful? Give feedback.
-
|
I think both the - type: listener
key: "@"
value: present(In English: Match a listener if it exists. The So we can tuck that inside a filters:
- not:
- type: listener
key: "@"
value: present
filters:
- type: target-group
key: "@"
value: emptyOr get a little more picky by only matching if we have no healthy targets: filters:
- type: target-group
key: "[].TargetHealthDescriptions[?TargetHealth.State == 'healthy'][]"
value: empty(In something closer to English: build a flat list of healthy targets across all target groups used by this ALB. Match the ALB if that list is empty.) Both of these filters were in place before the list-item filter existed. They could both probably stand to be refactored to derive from that filter. I imagine we'd want to deprecate the existing behavior because it's pretty awkward, but we would also want to avoid breaking existing policies. |
Beta Was this translation helpful? Give feedback.
-
|
As a small follow-up question, any reason why filters:
- not:
- type: listener
key: "@"
value: presentdoesn't work the same as filters:
- type: listener
key: "@"
value: absentI thought it would, but it appears to miss finding load balancers with no listeners or target groups assigned to them with the second form, but not the first one, and I don't understand the difference. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you @ajkerrigan , that helps a lot. One question I have about this is that we're looking for listeners, but what if we do not have listeners defined, but we still have targets created to target groups on the ALB? I'm not too much of an expert in ELB, but wouldn't that be a situation where it could "in theory" be active (although you'd still need to create the listener, maybe it was deleted for some reason), but still be in a semi-valid or easily fixable state that you could re-enable the ELB to work? What if I want to be absolutely certain that the ALB doesn't have any targets at all to them, irrespective of whether they have a listener defined? |
Beta Was this translation helpful? Give feedback.
-
|
It's possible to break an ALB by deleting its listeners, sure. In that case there wouldn't be any lingering target group references though, because the ALB<-->target group association comes from an ALB listener rule forwarding traffic to a target group. So if you start with an ALB that has listener rules forwarding traffic to a target group with registered/healthy targets, then you delete the ALB listeners, the target group can still have registered/healthy targets. That target group wouldn't display any association to the ALB with the deleted listeners, though it still could have ties to other ALBs. I'm not sure that's helpful though, I'm losing track of exactly what we're trying to filter for now 😅 |
Beta Was this translation helpful? Give feedback.
-
Describe the bug
Default value filters do not seem to work properly for app-elb matching
To Reproduce
See example below
Expected behavior
Match using the default filter and perform action against the matched resources
Background (please complete the following information):
Container:
cloudcustodian/c7n latest ccb73dcf0065 4 weeks ago 469MB
Policy: [please exclude any account/sensitive information]
custodian version --debugoutputAdditional context
When there is no target group/listener attached, these policies don't work.
2nd Notation
When I do attach a target group, the policy appears to match the resource even though it shouldn't because the target group/listeners are no longer EMPTY.
Trace from 1st policy above with target group attached
Trace from 2nd policy above with target group attached
Beta Was this translation helpful? Give feedback.
All reactions