This message was deleted.

[namespace/]name

e.g., to import a Deployment in the

foo

namespace:

import: "foo/my-deployment"

huh, i tried that, but it's not working 🤔

can you paste in the code snippet that’s not working?

const clusterIssuer = new k8s.yaml.ConfigGroup('cluster-issuer', {yaml: CLUSTER_ISSUER_YAML}, {provider, dependsOn, transformations: [asdf]});
function asdf(args: any) {
    return {
        props: args.props,
        opts: pulumi.mergeOptions(args.opts, {import: 'letsencrypt-prod'}),
    };
}

This is just a test resource to see if i could import a single resource.

oh, i think the problem is that you can’t import the

ConfigGroup

directly; import currently only works with the underlying resources, so the import name has to map correctly

won't the transform apply to the individual resources?

it will, but you have to make sure each of those resources is named

letsencrypt-prod

trying to give

import: whatever

to

ConfigGroup

fails because of the type mismatch (expected), and the transform applies to the cluster issuer (it's a config group but there's only one yaml element), but the import fails with

Preview failed: resource 'letsencrypt-prod' does not exist

maybe in a different namespace?

clusterissuers are namespaceless

oh, right

yeah, i don't know? it seems it changed?

from the example i linked:

function addImportForHelmChart() {
  return (obj: any, opts: pulumi.CustomResourceOptions): void => {
    if (obj != null && obj.metadata != null && obj.metadata.name) {
      opts.import = obj.metadata.namespace
        ? `${obj.metadata.namespace}/${obj.metadata.name}`
        : obj.metadata.name;
    }
  };
}

yeah but i get all kinds of errors with that, include type errors i have to suppress with

any

, and the docs say something different now

hmm, i’m fairly sure the k8s transformations support predates this, and may not be identical

mmm, you're probably right that i should have checked that reference. i do indeed get type errors though:

src/cluster-bits.ts:99:99 - error TS2345: Argument of type '{ provider: Provider; dependsOn: Output<any>; transformations: (() => (obj: any, opts: CustomResourceOptions) => void)[]; }' is not assignable to parameter of type 'ComponentResourceOptions'.
  Types of property 'transformations' are incompatible.
    Type '(() => (obj: any, opts: CustomResourceOptions) => void)[]' is not assignable to type 'ResourceTransformation[]'.
      Type '() => (obj: any, opts: CustomResourceOptions) => void' is not assignable to type 'ResourceTransformation'.
        Type '(obj: any, opts: CustomResourceOptions) => void' is missing the following properties from type 'ResourceTransformationResult': props, opts

99     const clusterIssuer = new k8s.yaml.ConfigGroup('cluster-issuer', {yaml: CLUSTER_ISSUER_YAML}, {provider, dependsOn, transformations: [addImportForYaml]});

hmm, that’s odd. perhaps something changed i’m not aware of. let me look into it

v1.7.1?

yeah, plus 1.4.1 on

pulumi-kubernetes

my

pulumi-kubernetes

is pretty old, let me try bumping it...

normally you shouldn’t have to run

tsc

. pulumi will run it as part of the

pulumi up

process

so it can import typescript from an external library?

oh, i think i misunderstood what you were doing

noted. will do that. thanks for the assistance.

pulumi-kubernetes is good

filed at https://github.com/pulumi/pulumi-kubernetes/issues/932 in case anyone comes through

I don’t know if this helps but I had a monorepo setup and when there are different versions of the same package being hoisted it’s possible to get conflicting types due to difference in instances of the library. Even if you don’t use a monorepo if it’s a library make sure you’re using peerDependecies so there’s not 2 Pulumi instances.

@prehistoric-account-60014 that's a good point to keep in mind, thanks. i don't think that's the case here, since i get a type error even in the library. and doing an

npm ls | grep pulumi

shows the same pulumi version for everything. but it is something i'll have to watch out for.

Even same versions that are duplicated would cause an issue. The way I checked myself was by running

yarn why @pulumi/pulumi

and making sure there was only one instance. Also keep in mind there are two transformation properties and each have different signatures. You might be mixing the two. One is in the second positional argument in the constructor, together with other options and the other one is in the third, together with the provider, etc.