https://pulumi.com logo
Join Slack
Powered by
<@UQ8K13T7X> i'm trying to use a custom dynamic pr...
# automation-api
p
@lemon-agent-27707 i'm trying to use a custom dynamic provider (resolved dns entries to ip's) with the automation api. But it cannot find 
<@UDNQQGNJF>/pulumi/cmd/dynamic-provider
. Weirdly enough this is backend dependent. Using cloud it works, but on an s3 backend it does not. Only difference between the code is adding this to the createOrSelectStack. Any idea's on the cause (or the solution obviously ;))
Copy code
projectSettings: {
              name: `bpaas`,
              runtime: `nodejs`,
              backend: {
                url: `<s3://xxx-xxxx-xxxxx?region=eu-central-1>`,
              },
            },
ok, i got somewhere. when using an s3 backend, it places the Pulumi.yaml and stack yaml file in a temporary folder, where the node modules of pulumi is not available
still weird this is backend dependent
l
@proud-pizza-80589 is this Automation API with an inline program using a dynamic provider?
p
yups
l
@proud-pizza-80589 if you say it works with our cloud backend, is it only the 
backend
property that you remove from the 
projectSettings
?
p
correct
e
Is this with fresh stack state for both filestate and service?
p
yes, a clean run in a bull queue worker for a new stack
maybe not so clean
Copy code
try {
        currentStack = await LocalWorkspace.selectStack({
          stackName,
          workDir: this.isDevelopmentMode ? `/tmp/${process.env['NAMESPACE'] || process.env['USER']}` : '/data',
        });
        await currentStack.cancel();
      } catch (error) {
        // swallow the error: stack does not exist
      }

      const stack = await LocalWorkspace.createOrSelectStack(
        {
          stackName,
          projectName: `bpaas`,
          program: async () => {
            return await pulumiProgram();
          },
        },
...
is it possible that the workdir for selectStack bleeds through to createOrSelectStack?
it is supposed to error out in step 1, and then create a new one
e
I don't think so, but if the dynamic resources already exist in the stack selected the dynamic provider might not even be getting started up
I strongly suspect your service stack already has data, and thats why it appears to work
p
i did try those cases, but i also have it on new stacks
e
That's very odd then. I can't see anything backend specific in the startup code 😕
p
yeah, stook me a wile to get it going, but by forcing the workdir to the calling dir it works just fine
2 Views
Open in Slack
PreviousNext
Powered by