hey guys, for

pulumi/datadog

Monitor resources, there is a plan to implement

life_cycle

? It could be really useful to avoid this issue: https://www.terraform.io/docs/providers/datadog/r/monitor.html#silencing-by-hand-and-by-downtimes

I'm running Pulumi (Typescript) on WSL...and every time I change our code, I probably spend 75% of the time trying to get Pulumi to run successfully. To start...I kind of feel like a weirdo trying to do this on WSL anyway 🙂 ... but it's just very non-deterministic for me. For example, in the past day, I'll run it...and just get a non-zero exit code. Run again, and I get a bunch of

error: Error: spawnSync /bin/sh EINVAL

... blow away node_modules and package-lock.yaml...npm install...run again...everything works fine. Switch stacks...spawnSync errors. Back and forth. Sometimes reinstalling Pulumi fixes it for a bit, sometimes not. Regardlesss, it has 3 or 4 different ways of failing...and I haven't changed any code... I'm wondering if there's some level of verbosity that I can be running that provides useful info for feedback?

So I'm a little new. Are Pulumi stacks able to be paramaterized/dynamic? For example I'd like to define a Pulmini stack for Pull Request sites/environments such that in my CI/CD pipelines I can have the PR trigger creation of an environment using Pulumi but passing in the PR branch name to isolate resources into their own domains and resource groups. Is this use case possible without static/generated YAML files for every PR site?

I know there were some issues at one point with Node v12.x. Has that stabilized now?

This is referring back to a previous question: https://pulumi-community.slack.com/archives/C84L4E3N1/p1580839270459300. I’ve rewritten everything to component resources now…So I have one that has a deployment + a Persistent Volume Claim. But how do I make it so that if the config of the deployment changes it doesn’t just try to update that deployment and tries to mount the same PVC, but also creates a new PVC?

i was doing

runtime.listResourceOutputs(k8s.apps.v1.Deployment.isInstance)

and now it gets a protobuf decoder error

any ideas?

For thouse who are interessed. I wrapped pulumi into a npm package so you don’t need to install it anymore via homebrew or global. Works for me pretty nice till now. https://github.com/Dev-Thought/pulumi-npm

We've got a number of loosely coupled stacks. Today a change in one broke a stack reference from another upon the invocation of that dependent stack. This, obviously, is suboptimal. Does Pulumi have or plan to add ways to communicate changes between stacks? (Honestly, for our purposes, a publish hook of some flavor that allows us to ping an SNS topic would be fine, but if there's a better pattern I'd love to hear about it.)

Is there a way to inspect the contents of a filearchive and/or assetarchive? See the structure, etc.?

I'm currently using aws-cdk, considering pulumi. I only have one question currently. If I were to use pulumi (I'm open to using any supported language, but preference is Python) would it be straightforward to package the deployment as a single binary. My hope is to hand over a binary to anyone with a linux box and, just by running the bin, have the deployment up and running. aws-cdk is making this hard, and the python support is weak, so pulumi seems like it may be a better fit for me.

Is

curl -sSL <https://get.pulumi.com> | sh && git clone <https://your.git.hosting/path/to/stack> && cd stack && pulumi up

that much of overhead?

It's not so bad, it just requires installing a dependency, which is sort of a bummer

You're going to need to install quite a few dependencies that the stack uses

What do you mean?

@shy-yak-78243 you could run pulumi in docker

But then they need docker installed 😛

Well, I've just started playing around, and using the currently recommended (?) TypeScript, and there's quite a few node modules to install before the

pulumi up

is able to do it's thing (which happens in the background, ish)

Oh, yes so that's exactly what I want to package up.

(which also means you need node, npm, and probably something else installed)

tar

?

But only docker. That’s one binary. Without docker you need each stack as a binary

But if you package it, you need to also take care of distributing the updated package of it.

Each stack as a binary is ok so long as the binaries all carry their dependencies

but I saw that it's beta

Good afternoon, I would like to know if it is possible to remove the id from the component name, I see it concatenated, I working with azure and c#

@incalculable-dream-27508 I don't know what you mean. I'd just upload new binaries to github with each release, and then people can

curl | sh

them

For me

git pull

is easier than having to figure out that there's a new binary to get and getting it 🤷

Hm, that's fair