(and most importantly, where i’d look for how it propagates error states, if for example some init-container might be crashlooping or otherwise not working)

< 1 day after tweet storming about the Kubernetes stuff, someone wrote a vscode extension: https://github.com/itowlson/vscode-pulumi-kubernetes

bananas.

trying to wrap my head around how i’d structure a smaller project of mine — is there any examples of something that depends on the outputs of a resource? .. i guess the mechanism would be used quite a lot outside of k8s scope as well, when standing up cloud infra but the configmap example might look like something i need in k8s world

okay, so looked a bit at the configmap example and there’s something i don’t understand from the README description in the folder https://github.com/pulumi/examples/blob/master/kubernetes-ts-configmap-rollout/index.ts the “update config with new name” and update dependent deployments — where exactly is this behavior encoded? is this a general thing with any object referring to a configmap? is this prevalent with other object dependency relationships elsewhere?

Why does let siteBucket = new aws.s3.Bucket(“s3-bob-pr000001”); result in a bucket name of s3-bob-pr000001-d16b3d1 ?

what exact effects does it have to make a resource A be the

parent

vs

dependsOn

of another resource B? I’m currently just arguing whether I should make the k8s namespace of my app the parent or dependsOn of the resources inside the namespace.

I'm aaaalmost there with getting Travis CI managing all infra. I got this:

kubernetes:apps:Deployment kube-system/kubernetes-dashboard updating 1 error. error: Plan apply failed: unable to fetch resource description for apps/v1beta2: Unauthorized

Is this a problem speaking to the k8s cluster? I'm using kubeconfig that comes out of the eks resource that is launched right above.

hi, is it possible to have set some sort of global config or secrets that can be reused across stacks and apps? In our case we have two common npm and gemfury tokens that we need in a lot places.

I'm getting errors provisioning gcp resources, e.g.

Plan apply failed: Error, failed to create instance unleash: googleapi: Error 403: Access Not Configured. Cloud SQL Admin API has not been used in project 563584335869 before or it is disabled. Enable it by visiting <https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview?project=563584335869> then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry., accessNotConfigured

I do have sqladmin.googleapis.com enabled, but 563584335869 is not my project.

Is there a way to add some code that only executes during the apply phase and not during the plan phase?

In my case I want to build a docker container and once it’s built do a docker run and run some tests on it.

The problem from what I can tell is my test code is firing during the plan before the image exists

chicken and egg problem

My test on line 26 can only run if the image has already been created, but at the plan stage it seems it’s not created yet so I get a image not found error

I know I could check if the image is there, but this got me to just thinking in general if there’s a way to say only run this stuff at apply time.

Seems like it might be more of an order problem

You should be able to import the isDryRun function from

@pulumi/pulumi/runtime/settings

Cool something new to add to my toolbox.

I may of mispoke after the plan runs I can see the image in my locker images docker images | grep bob

So this may be a case of my shell.exec tests code being called out of order

, before the plan creates the local image

This may be me not understanding the order of type script execution

I was reading that sequently

Or a burned mind trying stuff after a full days work

Okay... next quick question. When I see something like this:

function getLoadBalancer(args, opts) {
    return pulumi.runtime.invoke("aws:elasticloadbalancing/getLoadBalancer:getLoadBalancer", {
        "name": args.name,
        "tags": args.tags,
    }, opts);
}

How do I find the code for

aws:elasticloadbalancing/getLoadBalancer:getLoadBalancer

? For quick context, this is what I'm trying to do. Since I'm launching a service of type LoadBalancer on EKS, I then want to get the ELB object and create a Route53 Alias to it. Since I need ELB name to

getLoadBalancer

, but EKS gives me the DNS Name or Hostname, I wanted to write a new function to get LoadBalancer by that name. I presume this'll also help when I get to launching an Ingress Controller. Of course in your blog post this works great because when you launch a CloudFront distribution, you get a rich object back. Also tell me if I'm going about this all wrong. I have a hello world launching from EKS. Just need to wire up the last Route53 record.

heyho folks. I have some feedback on the project and stack naming. Currently as I understand it a stack is always more or less an “instance” / “deployment” of a project. Or in other words, each stack belongs to exactly 1 project. I think it is safe to assume that most organizations will have more than 1 project. However for some reason the pulumi cloud app requires each stack name to be unique across the entire organization, not just within the project. In practice that means if I want to use common stack names like:

staging

or

prod

I always have to prefix or suffix the stack name with the name of the project in which it is contained, which seems pretty redundant and actually leads to really long stack names for no apparent reason. I think it would be better if stack names are only required to be unique within a project. To depict this via an example: Ideally It’d like to have names like this: project: my-fancy-project - stack: staging - stack: prod However because of the limitations above I have to use names like this: project: my-fancy-project - stack: my-fancy-project-staging - stack: my-fancy-project-prod The pulumi CLI also shows in the preview an odd and quite long looking name like this: TYPE NAME pulumi😛ulumi:Stack my-fancy-project-my-fancy-project-staging A really concrete problem with the long stack names is that the

name

column of the pulumi😛ulumi:Stack resource in the

pulumi preview

uses up so much space that on a notebook there’s barely any space left for the

Info

column and I’m often not able to decypher what a particular error message in the Info column actually says.