-
Notifications
You must be signed in to change notification settings - Fork 117
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
Panic creating ConfigMap. #559
Comments
I suspect this is caused by computing the ConfigMap metadata rather than creating it directly. The provider currently tries to set an autoname annotation during the preview phase, and I don't think it's handling this case correctly since the metadata isn't yet available. |
Looks like the OP was able to work around by creating the resources in separate updates, so I'm going to punt on this issue for M23 |
We can't let panics in the CLI go for another sprint. Assigning @ellismg for load balancing. |
This is caused because |
I hit the same panic a few times in different places throughout the last week as it seems to be triggered whenever you use an auto-named kube configmap that contains a value from a newly created resource. Since it panics during the preview it sent me on a few wild goose chases trying to diagnose which resource is causing the issue - often the output log is something like "Event hub transport closing. <<panic stacktrace>>". I was able to work around it in this case with keyvaults but it involved publishing a pre-release npm package with configmap creation commented out then another publish to create that so it was non-trivial. One example where I couldn't work around it was creating an Azure EventHubNamespaceAuthorizationRule and save its keys to a kube configmap - its not possible to create one of those rules and then retrieve its system-generated keys in a separate step. Thanks a lot. |
During preview, an object's metadata bag may be computed (or be known but contain values which are computed). This could happen, for example, by using `apply` to take an output property from a yet to be created resource and use it to build part of an object's metadata, like we saw in #559. In these cases, we incorrectly panic while attempting to extract out the metadata.lables or metadata.annotations members of the metadata object, when trying to set an annotation or label. To fix this, we now treat requests to set annotations or labels as no-ops if the metadata object is computed (or the label or annotation values inside the metadata object are computed). This allows preview to continue, as expected. During a real update, we will not have computed values and so we will be able to correctly set the labels as we expected. Fixes #559
During preview, an object's metadata bag may be computed (or be known but contain values which are computed). This could happen, for example, by using `apply` to take an output property from a yet to be created resource and use it to build part of an object's metadata, like we saw in #559. In these cases, we incorrectly panic while attempting to extract out the metadata.labels or metadata.annotations members of the metadata object, when trying to set an annotation or label. To fix this, we now treat requests to set annotations or labels as no-ops if the metadata object is computed (or the label or annotation values inside the metadata object are computed). This allows preview to continue, as expected. During a real update, we will not have computed values and so we will be able to correctly set the labels as we expected. Fixes #559
Please forgive the convoluted example but I'm getting a panic from the following code. I've stripped the functionality down to the bare minimum to cause it. If I create the KeyVault in one update and then create the configmap in the second it all works.
The method to get the kube config from a keyvault works everywhere else, but fails in this case.
Panic output is at the bottom.
The text was updated successfully, but these errors were encountered: