https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
g
Pulumi acts the same as 
kubectl
. It will read ambient config in the same fallback order, including 
$HOME/.kube/config
i
I wouldn’t think it would fallback since the 
Namespace
I am creating is using an explicit 
{ providers: { kubernetes } }
g
Yeah, if you set a provider, it should use those creds rather than anything ambient
i
I guess the context name would have been identical though, same stacks just rebuild today
@gorgeous-egg-16927 so I 
echo "" > $HOME/.kube/config
and 
pulumi up
and I get 
error: unable to read kubectl config: invalid configuration: no configuration has been provided
my concern is this is going to occur on ci, since it is a new vm every time
what is a valid empty config?
g
Hmm, are you sure all of your k8s resources have a provider set? It could be a bug otherwise
i
In this stack I have nothing but a Namespace. let me simplify to verify, it does use the kubeconfig output from another stack
Namespace
uses 
CustomResourceOptions
which takes 
provider
whereas my 
opts
utility outputs 
ComponentResourceOptions
which takes 
providers
(plural).
two issues here:
1. my env must be screwed up because I don’t see a ts error - I’ll fix that
2. that api seems inconsistent, since I’d expect the Namespace options to look like other options
Regardless, my env needs fixed because I should see that as a ts error.
With the corrected options, it works with an empty .kube/config
c
@important-leather-28796 the component resource options could have multiple resources with different providers
so, it needs to take many of them.
possibly.
i
bizarre thing is my ts passes and it is clearly wrong. looking at that now, but I’m pretty well versed here and it’s not right
c
this is because it needs to support arbitrary providers.
oh wait
no, this should be right. you need 
providers: { kubernetes: yourProvider }
i
no, keys are diff 
provider
vs 
providers
c
yeah but it’s 
any
type
i
so I should see a ts error
c
no, because you could have providers with arbitrary names. Not only the official ones like 
aws
, 
kubernetes
, 
azure
, but also any third party, maybe custom ones you wrote, etc.,
so 
providers
needs to be able to take a bag of any providers, with any names.
if that makes sense.
i
value is but the key is not. Custom is 
provider?: ProviderResource
and Component is 
providers?: Record<string, ProviderResource>
currently the result of this fn is what typechecks for either
Copy code
export const opts = (overrides: ComponentResourceOptions = {}): ComponentResourceOptions =>
  merge({ providers: { kubernetes } }, overrides)
which makes no sense
c
the keys will always be string, no?
kubernetes
is getting “desugared” into the key called 
kubernetes
i
key is always a string and will error if used in a single file, but not if used by the function
c
I’m not sure I understand.
i
This should be failing to ts check:
Copy code
export const namespace = new k8s.core.v1.Namespace(
  name,
  {
    metadata: {
      name,
    },
  },
  opts(),
)
pulumi types are right
my tsc is not failing it
c
opts
returns 
ComponentResourceOptions
, right?
i
right, but Namespace takes 
CustomResourceOptions
c
Oh I see.
i
tsc not failing it led me to this wierd issue with a stale .kube/config
I’m expecting to always use the explicit provider and here I am finding tsc not erroring
c
hmm
one second.
Copy code
const ns = new k8s.core.v1.Namespace("foo", {}, { providers: { foo: <any>"bar" } });
doesn’t work for me.
let me try to reproduce
i
right, but you aren’t using a different file for the fn
in a single file i get the error correctly
so pulumi types verified correct
c
what’s merge?
i
deep object merge
c
I mean is it a custom function?
i
ns.ts
Copy code
import { opts } from './provider'
import * as k8s from '@pulumi/kubernetes'
import { Config, getStack } from '@pulumi/pulumi'

const name = new Config('kubernetes').get('namespace') || getStack()

export const namespace = new k8s.core.v1.Namespace(
  name,
  {
    metadata: {
      name,
    },
  },
  opts(),
)
provider.ts
Copy code
import * as k8s from '@pulumi/kubernetes'
import * as stack from './stack'
import { ComponentResourceOptions } from '@pulumi/pulumi'
import merge from 'lodash/merge'

export const kubernetes = new k8s.Provider(stack.infrastructurePath, {
  kubeconfig: stack.infrastructure.getOutput('kubeconfig'),
})

/**
 * default kubernetes provider opts
 */
export const opts = (overrides: ComponentResourceOptions = {}): ComponentResourceOptions =>
  merge({ providers: { kubernetes } }, overrides)
regardless of the merge
I took it out and did a spread, the opts fn is explicit with return type, so it should fail
I’ll mod something for you quick
c
huh sure enough
i
this fn in the provider file still typechecks for me
Copy code
export const opts = (): ComponentResourceOptions => ({ providers: { kubernetes } })
c
Copy code
export const kubernetes = <k8s.Provider>(<any>"foo");

export const opts = (
    overrides: pulumi.ComponentResourceOptions = {},
): pulumi.ComponentResourceOptions => {
    return { providers: { kubernetes }, ...overrides };
};

const ns = new k8s.core.v1.Namespace("foo", {}, opts());
totally typechecks lol
i
it’s clearly not providing 
CustomResourceOptions
must be a tsc bug
makes no sense
c
but so does this:
Copy code
const os: pulumi.ComponentResourceOptions = <pulumi.CustomResourceOptions>{};
strange.
that should definitely be a bug
i
the pulumi types are simple so there isn’t something fancy occurring.
bizarre, I’ll check my tsc version etc
c
second one fails:
Copy code
const os: pulumi.CustomResourceOptions = <pulumi.ComponentResourceOptions>{};
const os2: pulumi.CustomResourceOptions = { providers: {} };
weeeeeiiiird
and then somehow this succeeds:
Copy code
const os2: pulumi.CustomResourceOptions = <pulumi.ComponentResourceOptions>{ providers: {} };
this fails:
Copy code
const os2: pulumi.CustomResourceOptions = { providers: undefined };
@important-leather-28796 I apologize, I have no idea what’s going on here.
i
np - definitely a ts problem
c
how odd
i
my tsc is at 3.2.4, what is yours. I’m going to update
c
3.0
lmk if you see it in the most recent ts
i
ok
c
i’ll try to get an isolated case for a bug repory
compiles:
Copy code
export interface ResourceOptions {
    foo?: boolean;
}

export interface CustomResourceOptions extends ResourceOptions {
    bar?: string;
}

export interface ComponentResourceOptions extends ResourceOptions {
    bars?: string;
}

const os: CustomResourceOptions = <ComponentResourceOptions>{};
does not compile:
Copy code
export interface ResourceOptions {}

export interface CustomResourceOptions extends ResourceOptions {
    bar?: string;
}

export interface ComponentResourceOptions extends ResourceOptions {
    bars?: string;
}

const os: CustomResourceOptions = <ComponentResourceOptions>{};
def. a TS bug.
@important-leather-28796 so, one of our engineers, @lemon-spoon-91807 says that this is actually all on purpose, coming from a set of heuristics in the TS compiler.
Turns out: I lied.
Sorry.
l
Yes 🙂
this is just how TS works
which can def seem wonky at times
c
It makes sense when you think about it.
I mean, when you think about it as a pile of heuristics
i
This can't be right. One interface has a key provider and the other has a key providers. There is no reason for this to statically type check
l
one is optional
and typescript is loosygoosy
i say that as a person who helped create the first two versions of TS
and who helped define the language 😄
so you can blame me for some of this
i
Logically this is a ts bug, and I'm expecting > 99.9999% of users will think of it (as shown in this case) as a bug. I think we should still file it
l
File against 'ts'?
i
Yes
l
I mean... thsi has been behavior it has had since pre-1.0
it's definitely something we knew about and accepted.
i
Doesn't mean it should not be improved
l
that said, i'm not opposed to you filing a bug here 🙂
if you really think they should improve
i can hook you up with the current PM on the team
to help draw some attention to it.
i
Or change the interface on namespace so I cannot make the mistake
I have never encountered it and we have a large ts codebase
l
that's tricky given TS's structural nature
we could attempt to look for mistakes at the runtime level
i.e. if you pass 'providers' to Custom, or 'provider' to Component
note: we hit this several times ourselves when writing the TS compiler 🙂 Fun times.
i
Lol
l
i'll add the runtime check
give me a minute
i
Definitely at least a runtime check is good
I just don't want things running locally only to have them fail on CI, this is that exact case
l
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by