-
Notifications
You must be signed in to change notification settings - Fork 123
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
[Bug]: ELBv2 Provider v1.5.0+ LBListener 'panic' #1352
Comments
Hi @lajchon, Thank you for the report, is the issue also reproducible in provider v1.7.0? |
@turkenf , it appears to still be an issue after updating the provider to v1.7.0. |
Adding voice to this issue. It also occurs in 1.6.0 and 1.6.1 as well. In our scenario, the LBListener can cause it to crash within 5sec or so. |
Yes, I have also encountered this problem and don't know what to do,Looking forward to the next version resolving this issue. |
Hello folks, Thank you for your comments on this issue. It can be reproduced with provider version |
@turkenf maybe this helps: pulumi/pulumi-aws#3429 |
I'm seeing the same thing with the following setup:
Here is the resource I create: apiVersion: elbv2.aws.upbound.io/v1beta2
kind: LBListener
metadata:
labels:
environment: dev
name: dev-us-east-1-private-consul-nlb-tcp-8500
region: us-east-1
subnet-type: private
vpc-name: dev-us-east-1
name: dev-us-east-1-private-consul-nlb-tcp-8500
spec:
forProvider:
defaultAction:
- targetGroupArnSelector:
matchLabels:
environment: dev
name: dev-us-east-1-private-consul-nlb-tcp-8500
region: us-east-1
subnet-type: private
vpc-name: dev-us-east-1
type: forward
loadBalancerArnSelector:
matchLabels:
environment: dev
name: dev-us-east-1-private-consul-nlb
region: us-east-1
subnet-type: private
vpc-name: dev-us-east-1
port: 8500
protocol: TCP
region: us-east-1 As soon as that resource is applied, the elbv2 provider panics:
Once it panics, I can't actually describe the resource because the webhook isn't running anymore. The listener does get created on the AWS side though, so I think this isn't a bug on terraform but on whatever is processing the response from terraform - maybe not understanding that a field is nullable if the action is a forward action? Note that the first example on the docs here is also broken - if you omit the |
This issue seems related - I wonder if this maybe has to do with block handling somehow? |
Based on the documentation, I tried changing the apiVersion: elbv2.aws.upbound.io/v1beta2
kind: LBListener
metadata:
labels:
environment: dev
name: dev-us-east-1-private-consul-nlb-tcp-8500
region: us-east-1
subnet-type: private
vpc-name: dev-us-east-1
name: dev-us-east-1-private-consul-nlb-tcp-8500
spec:
forProvider:
defaultAction:
- forward:
stickiness:
duration: 1
enabled: false
targetGroup:
- arnSelector:
matchLabels:
environment: dev
name: dev-us-east-1-private-consul-nlb-tcp-8500
region: us-east-1
subnet-type: private
vpc-name: dev-us-east-1
weight: 0
type: forward
loadBalancerArnSelector:
matchLabels:
environment: dev
name: dev-us-east-1-private-consul-nlb
region: us-east-1
subnet-type: private
vpc-name: dev-us-east-1
port: 8500
protocol: TCP
region: us-east-1 The error is the following:
If anyone knows of a good way to disable sending a weight parameter when the load balancer type is |
Digging into the weight issue, I believe thats an upstream bug due to how it handles the |
Hello folks, thank you for your interest. I dug into this issue a bit: The problem seems to be caused by spec.forProvider.defaultAction.forward being null, as you stated. We started to encounter this problem after bumping the terraform provider from Also, as @jetersen mentioned, Pulumi has faced the same issue, and they have fixed it in the bridge provider. |
I downgraded the provider to v1.3.0 to avoid this error until the issue is resolved. |
Note: downgrading may not be useful if you are using other providers to interact with the elbv2 provider. In my case, I need the |
Just FYI, panics no longer crash the pod as of latest release, v1.12.0, thanks to crossplane/upjet#428. |
Does it apply the resource and hold it's state though? |
No, it does not. As of v1.13.0, while the panic no longer crashes the pod, the resources do not apply. In stead you get a simple little warning in the logs:
I'm assuming the null value is from the "forward" variable as mentioned. |
We are also experiencing this issue with v1.13.1. In our case, the pod no longer goes into a CrashLoopBackOff state. However, we observe that while the load balancer listener is created, it fails to reconcile properly.
|
Did someone tried to specify the targetGroupArn via: https://marketplace.upbound.io/providers/upbound/provider-aws-elbv2/v1.14.0/resources/elbv2.aws.upbound.io/LBListener/v1beta1#doc:spec-forProvider-defaultAction-forward-targetGroup |
Yes that also doesn't work, it throws an error saying invalid value,
The invalid value error suggests to add
|
The most recent merge looks to have resulted in 1.15 ... has anyone tested that yet? |
This issue is under active development. There were changes upstream in Terraform that is causing this behavior and we've identified the root cause. We'll likely have a fix ready for this in next week's release. |
1.16 has now been released and this issue closed. Anyone else test this yet? I guess Ill do it ... |
Is there an existing issue for this?
Affected Resource(s)
elbv2.aws.upbound.io/v1beta1, Kind=LBListener
Resource MRs required to reproduce the bug
Steps to Reproduce
Deploy elbv2.aws.upbound.io/v1beta1 LB, LBTargetGroup and LBListener with v1.4.0 is successful.
Bump elbv2 Provider version to v1.5.0 or v1.6.0, an
Observed a panic: value is null
is loggedWhat happened?
After bumping version from v1.4.0 to v1.5.0+, the following is logged for existing LBListener:
When attempting to create a new Listener with elbv2 v1.5.0, Listeners are created correctly and associated with Load-Balancer, but the following status is eventually returned:
Relevant Error Output Snippet
No response
Crossplane Version
1.16.0
Provider Version
1.5.0
Kubernetes Version
No response
Kubernetes Distribution
No response
Additional Info
No response
The text was updated successfully, but these errors were encountered: