-
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
kubernetes.yaml.*
produces a TypeError: Cannot read properties of undefined
#2038
Comments
kubernetes.yaml.*
produces an TypeError: Cannot read properties of undefined
errorkubernetes.yaml.*
produces a TypeError: Cannot read properties of undefined
error
kubernetes.yaml.*
produces a TypeError: Cannot read properties of undefined
errorkubernetes.yaml.*
produces a TypeError: Cannot read properties of undefined
@omninonsense thanks for the great repro! Would you please consider upgrading your provider to 3.19.4 and double checking it is actually being used?
Also if this still occurs could you check the output of |
Thanks for looking into this, @viveklak! So, with (output from
I still get:
The output of {
"version": 3,
"deployment": {
"manifest": {
"time": "2022-06-27T15:34:42.722246+01:00",
"magic": "not sure if this is secret or not, so I removed it",
"version": "v3.35.1"
},
"secrets_providers": {
"type": "service",
"state": {
"url": "https://api.pulumi.com",
"owner": "silico",
"project": "infra",
"stack": "sandbox"
}
}
}
} This fails during the plan/review phase (rather than when when applying). Also, this is not from the repro repo, but a real project, but the structure is largely the same. |
Also, this seems to be happening regardless of whether I disabled or enabled the default Kubernetes provider. |
@omninonsense ah so this is failing with an empty/brand new stack? |
@viveklak Yup, it doesn't seem to make a difference whether it's empty or if I add it to an existing stack |
Confirmed this is happening without disabling default kubernetes provider - you just need to use |
Investigating further - it is indeed the case that the invoke never actually makes it to the underlying provider. The issue in my repro was that if the underlying kubernetes provider has unknowns for its configuration, the provider is marked as unconfigured: https://github.com/pulumi/pulumi/blob/c9ba17d450f3717e006d7ce0be7736c4f0486447/sdk/go/common/resource/plugin/provider_plugin.go#L505 This is the reason why the call to pulumi-kubernetes/sdk/nodejs/yaml/yaml.ts Line 2892 in 763ddca
Granted an empty yaml body should be handled better here of course, but it seems unfortunate that we can't invoke the yaml decode function in previews (thus not be able to provide a preview of the resources to be created by loading the Thoughts @Frassle? |
A hacky workaround for now would be to either:
|
So either we should only support Output based invokes, or we should only allow immediate values to provider construction. Because otherwise you end up in this state where we don't have a provider yet because of unknowns but you can start an invoke with a non-output response which can't indicate unknownness. Short term we could error out the invoke if the provider was unknown? That's probably a better error than returning undef. |
I think I have the same issue in my small demo repo now. I create a aks cluster, than I want to use the config when creating the cluster to create a provider that I use to apply some kubernetes manifests, and it fails with:
If I use the default provider it seems to work. @Frassle , I don't think allowing immediate values to create a provider is the way to go, especially with kubernetes. I can definitely see scenarios where you have your core infrastructure where you create your cluster AND also add common things to the cluster like istio, linkerd, traefik and things like that. In those scenarios I do think you want to create the cluster and then use the config you get from the cluster creation to create the provider to apply those things. |
@Frassle apologies I dropped the ball on following up here. Should we track an issue here on pu/pu to do the above? |
This seems to happen in multiple ways. Similar issue, but the error I get in eks is this:
|
The plan here for the time being is to handle the empty response received in the various component resource implementations as a signal that no preview is available (due to an unconfigured provider). i.e. in such situations rich previews for resources under the config file etc. resources would not be possible. |
Ran into the same issue with .NET SDK. It manifests somewhat differently by throwing The workaround we have tried is to conditionally set provider arguments depending on whether the code runs in preview or not, like so: new Kubernetes.Provider ("kube",
Deployment.Instance.IsDryRun
? new Kubernetes.ProviderArgs ()
: new Kubernetes.ProviderArgs { KubeConfig = cluster.KubeConfig }) What are the possible downsides of this approach? For the record, the change that triggers this new behavior is 763ddca |
Hi @illinar. This actually seems like a pretty reasonable workaround. As such the specific invokes in question don't actually leverage anything salient about the underlying kubernetes provider and its mostly used as a mechanism to offload yaml processing to a language agnostic helper in the provider through an RPC. The only issue with this is if you were to set the disable default providers option, the dry-run preview would fail. |
@illinar's suggestion works. For TypeScript: import * as k8s from '@pulumi/kubernetes';
import * as pulumi from '@pulumi/pulumi';
import { cluster } from './cluster';
export const kubeProvider = new k8s.Provider('kube-provider', {
kubeconfig: pulumi.runtime.isDryRun() ? undefined : cluster.kubeconfig,
}); and then: export const dashboard = new k8s.yaml.ConfigFile(
'dashboard',
{
file: 'https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.0/aio/deploy/recommended.yaml',
},
{ provider: kubeProvider },
); |
Yes, we've realized this as well. Modifying provider state causes the diff between preview and deployed configurations 😞 |
This is breaking our production workloads please consider to revert PR that is causing this behaviour |
Apologies for the delays here. We have prioritized this issue and are actively working on it. We can't revert the PR as it is fundamental contract with the Pulumi engine to support other important use cases such as disabling default providers etc. We will instead follow the approach mentioned here: #2038 (comment) Note if you are being blocked here, the recommended workaround for the moment is here: #2038 (comment) |
I suspect #1987 may be related as well. Edit: Confirmed. Here's a repro: https://github.com/phillipedwards/pulumi-helm-error |
What happened?
If the default kubernetes provider is disabled, the
kubernetes.yaml
"submodule" doesn't work as expected. I'm not entirely sure if this is related to disabling the default provider, but I assume it is.Steps to reproduce
I've created a small reproduction in omninonsense/pulumi-repro.
But the general steps to reproduce it should probably be:
kubernetes.yaml.ConfigFile
(or others) with an explicitopts.provider
Expected Behavior
I expected it to apply the manifests using the provider passed via options.
Actual Behavior
I received the following error:
Versions used
Additional context
There's a hardcoded AWS
providerCredentialOpts.profileName
(set to"sandbox"
), which will probably need editing in the repro repo. There's also a bunch of AWS SSO and RBAC stuff, but I think that can largely be ignored (I yanked this from some existing code).Also, the issue isn't present when "manually" creating k8s resources using the native TypeScript API.
Also, I realise the title is a bit poor, but I'm not sure
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: