https://pulumi.com
Join Slack
Hi, I'm bumping into a(nother) wall with outputs and inputs: How can I use an output in an import st...
# general
l
Hi, I'm bumping into a(nother) wall with outputs and inputs: How can I use an output in an import statement?
Copy code
var testNamespace = new Rancher2.Namespace($"testNamespace-{managedCluster}", new Rancher2.NamespaceArgs
                {
                    Name = "testnamespace",
                    ProjectId = Project.Id,
                },
                new CustomResourceOptions
                {
                    Provider = rancherProvider,
                    ImportId = Project.Id
                }
            );
'ProjectId' resolves fine, but 'ImportId' does not 😞
l
You should not want to do that. You import exactly once ever, so you don't need to get the code programmatically. Look it up, type the value in there, and import. Once you're finished importing, remove the importid.
It may help to think about the flow. The Namespace is declared at runtime and deployed / managed at deploytime. The Project is managed at deploytime, so its Id cannot be known until then. If you want to declare a Namespace that it dependent at construction on a value that isn't available until deploytime, that means you cannot construct it until deploytime. Which is a thing you want to try very hard to avoid.
l
we might be importing hundreds or even thousands of existing namespaces into various projects based on project name mapping, so I would very much like to do this programmatically instead of hard-coding it
l
Right. There are ways to import via CSVs, or you can use Insights2.0 I think? But you do not want to have the logic that is used for all time after importing to be polluted with logic that is specific to the first run only.
You may consider generating those ids and "mail merging" them into your code. But you cannot do what you want correctly in "normal" code.
l
we discovered that we can place the entire resource/import statement inside an apply block, that will cause the project to resolve just fine.
l
It will, but then you'll have to remove the import code and the apply block after the first run. Which is just as hard. And more prone to introducing more serious bugs.
Better do the bulk import, I think?
Actually, maybe not. Since you've already written the good code for managing this, the bulk import would probably make your life harder. You'd have to remove the good code, bulk import, then reword the generated code progressively, during multiple up operations. Could be even worse than removing the apply block.
However, do remember to remove those apply blocks. They're only for the initial import. When you're removing the importId, remove the apply blocks too.
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