-
Notifications
You must be signed in to change notification settings - Fork 4k
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
[aws-eks]: CDK uses integer for timeout; Helm expects duration #8718
Comments
cdk 1.46.0 has a pinned version of aws-lambda-layer-kubectl 2.0.0-beta2, which should be immutable.
I haven't tried the helm timeout feature yet. Was it working and now it just failed? |
No @pahud It was the first time I used it as well. Then it is not related to your last change. As for as I can find in the Helm documentation the |
I believe we just supported Helm --timeout in #8338 by @eduardomourar Hi @eduardomourar , any idea on this issue? |
I believe it was my mistake, so I will gladly fix it. |
@eduardomourar thanks! let me know if you need assistance. |
This resolves a problem with timeout parameter being passed down to Helm. The Helm version used (v3) expects a duration (in our case, in seconds such as `600s`) instead of integer. fixes #8718 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Wanted to test the new timeout parameter in the EKS Helm construct as I had problems deploying a large Helm chart like the prometheus-operator chart. But I just ran it and hit a problem: CDK translates the timeout to an integer value in seconds but the Helm version used (v3) expects a duration specification. So 900s instead of 900.
Reproduction Steps
Error Log
Environment
Other
Not sure if this could be related to an upgrade @pahud is working on in aws-lambda-layer-kubectl?
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: