Can you give that a shot instead and see what the result is? If it fails I’ll help you debug it. 🙂

@creamy-potato-29402 log output from pulumi

@glamorous-printer-66548 great!

Also terrible!

@white-balloon-205 and I will spend some time chatting about this tomorrow and I’ll try to get a fix out ASAP — hopefully before the PR ships.

@creamy-potato-29402 I have another observation / request. As you can see above I’m injecting a short-lived access token into the docker build command (via

password: execSync('gcloud auth print-access-token').toString('utf8'))

). This access token changes on every

pulumi up

invocation and because of this pulumi shows the resource as updated on every invocation. I’m not sure if it’s a good design decision that pulumi considers the password / access_token part of the permanent state / checkpoint of the resource since it’s more or less a secret that it just needed to create the resource but not a crucial part of the resource itself (i.e. unlike a password of a database resource). Also for GCR there is no classic notion of a long lived username / password (see https://cloud.google.com/container-registry/docs/advanced-authentication) . I think the easiest / quick-win for me would be if you allow to disable authentication (i.e. skip

docker login

) since my local docker is already authenticated automatically via gcloud which is registered as docker credential helper (see also https://cloud.google.com/sdk/gcloud/reference/auth/configure-docker).

hey, guys. Is there any instructions on how to go from the examples approach of having all pulumi files in the root of the directory to placing them in a .pulumi folder? Maybe a flag that should be passed on when creating the stack, updating and so on?

Only indirectly related to Pulumi - but really nice post from @tall-librarian-49374 on the front page of HN right now. https://news.ycombinator.com/item?id=17949694 https://mikhail.io/2018/08/serverless-cold-start-war/

this reminds me of GraalVM promise of fixing cold start on Java lambda bits

https://github.com/pulumi/examples/tree/master/aws-ts-eks is not working for me on pulumi 0.15.1 and node 10. Error is :

error: Error: invocation of aws:index/getAmi:getAmi returned an error: invoking aws:index/getAmi:getAmi: Your query returned no results. Please change your search criteria and try again.

ok quick fix PR : https://github.com/pulumi/eks/pull/4

Thanks @white-balloon-205 for posting! It's more directly related to Pulumi since all AWS and GCP code for testing was done with Pulumi. I've been firing 100x of lambdas with a simple javascript array, very handy!

Interesting read @tall-librarian-49374

Hi, I am curious if the kubernetes module now supports specifying a namespace for helm charts? I tested with the following:

Am I calling the namespace incorrectly?

It does support a

namespace

argument, but it is currently up to the Helm chart to respect that setting. Providing a

namespace

argument boils down to passing the

--namespace

flag to

helm

, which sets the

.Release.Namespace

variable when executing the chart's templates. The chart author is responsible for adding the appropriate uses of the

.Release.Namespace

variable.

Does that make sense?

interesting, as I can run the chart manually with that flag and have it go to

kube-tools

hey folks, this is a bit OT: Do you know a good CI/CD system / technology / service which allows using a real programming language instead of YAML for expressing complex pipelines?? I just know of Jenkins Pipeline (Groovy), TeamCity (Kotlin Script) and Airflow (Python), but all of these have significant maintenance burden. I’d like to have something a la CircleCI but without YAML.

Threads don’t do snippets I guess. Anyway:

Here is the core of the example — ~15 lines of code that incrementally roll out a staged deployment, gated on Prometheus metrics.

From here: https://github.com/pulumi/examples/tree/master/kubernetes-ts-staged-rollout-with-prometheus

In time, I’m hoping that we will have enough tools that you don’t need to use, e.g., Jenkins.

If you want to do only Kubernetes, Argo is worth a shot.

Hmm, I’m not sure if that’s what I had in mind, but interesting nevertheless. What happens when the P90 latency is > 100,000 microsends in your example? Does it reject the promise returned by

util.checkHttpLatency

and in turn aborts the deployment?

Yeah.

I see, good to know

Yeah, what I’m looking for is basically a pipeline execution environment which executes arbitrary scripts as steps and has gates (incl. manual approval gates) in between. I expect many pipeline steps to just invoke pulumi, but I don’t see pulumi making a CI/CD platform completely obsolete as of now.

yeah, me neither.