Every time I think I think I have this sorted out,...
# typescript
c
Every time I think I think I have this sorted out, I realize I don't.
Property 'getProvider' is missing in type 'OutputInstance<Deployment> & LiftedObject<Deployment, "id" | "apiVersion" | "kind" | "metadata" | "spec" | "status" | "urn">' but required  typescript (2741) [308, 5]
l
Can you convert this to a text snippet? It's a huge post, moving the code to a snippet makes it collapse, which makes browsing the channel easier.
There shouldn't be any need for the provider to be apply()ed. And provider should (almost) never be an arg. It should be available through opts (usually).
c
Ok 1 sec
Here we go
l
This looks like code in a ComponentResource. Was args.provider created via
new k8s.Provider()
or similar? You should be passing these sorts of providers in via opts. Hopefully there'll be a way to avoid creating this Deployment inside an `apply()`; it's never good to create resources inside an apply(), and it's almost always avoidable.
For example, changing
Copy code
`--node-group-auto-discovery=asg:tag=<http://k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/${clusterName}|k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/${clusterName}>`
to
Copy code
pulumi.interpolate`--node-group-auto-discovery=asg:tag=<http://k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/${args.clusterName}|k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/${args.clusterName}>`
would mean you can remove
clusterName
from the apply().
That is, assuming that command is an array of Input<string>. If it's not, you can still use apply() around the lowest level that does handle Inputs. Let me check the API docs.
Confirmed that command is suitable for this syntax.
Copy code
command?: pulumi.Input<pulumi.Input<string>[]>;
(I wish they'd put Input / Output back into the API docs; there's plenty of times when knowing that something is
Input<Input<string[]>>
is important; presenting it in the API docs as
string[]
hides important information.)
c
Thanks @little-cartoon-10569! A colleague and myself were just talking about the provider today and whether passing as an opts on a ComponentResource would be better but I hadn't tested a different approach yet. Would provider be inherited or would I access it via
opts.provider
instead?
l
It's not implicitly inherited (afaik), but best practice is to pass the ComponentResource's opts to every child resource. Generally, only the parent property needs to change. Somethings, the protect property.
The only time you need to be careful is if your ComponentResource groups resources with different providers. You should probably check at the top of the constructor that all the required providers are included.
I usually store opts as a member property (this.opts) and define
private parentOpts(parent: Resource) { return { ...this.opts, parent: parent }; }
c
Great! Thanks so much!
l
If you want to pass a custom provider to a component resource, make sure to use the
providers
(plural!) resource option. See the docs on this: https://www.pulumi.com/docs/intro/concepts/resources/components/#inheriting-resource-providers Within the implementation of your component, you do not have to pass the provider(s) to your child resources. You do have to set the
parent
option on the child resource pointing to the component. Provider lookup always starts at the resource itself and traverses the parent link via the component all the way up to the stack resource. Each resource without an explicit parent has the stack as its implicit parent where the default provider is resolved.
c
Thanks @limited-rainbow-51650!