Because if that’s the case, it still needs to build it and compare final hashes in order to decide if something needs to be pushed or not. But the build aspect needs to happen - which makes it less idempotent, if something is changed upstream, maybe some dependency or whatever - obviously a dockerfile should be as idempotent as possible, but still room for errors, I am just figuring out how it works so I can make a better decision.

It runs docker commands under the hood

It seems like @loud-battery-37784 was correct. It needs to do a form of “get or make” conditional.

@broad-dog-22463 To clarify, docker commands under the hood is building - but will Pulumi compare hashes before deciding to push to the registry/repository?

Yes

It will not update an image in the registry unless it has changed

But if that image changes outside of Pulumi then Pulumi won’t know that without a Pulumi refres

As it keeps track of the state

Let me clarify a bit further: The problem here is that the image used for a

Deployment/Pod

spec is computed from whatever Pulumi gives us as a result of its

awsx/ECR

API. It is not manually typed by us, we’re relying on the output of

const image = buildAndPushImage(name: "app:23", pathOrBuild: "./app")

To give consistent values so the only change is the

replica

count when Pulumi speaks with k8.

I don’t know what further clarification you need here?

We have examples of this in Pulumi/examples that you can test out and try it and see if changing the replicaCount does anything differently

What do you need the experience to be?

The output of that command is stable as long as it’s not a container that is changed outside of Pulumi’s control

Ok, I think I get it. You’re literally relying on Docker and nothing more - which is what I would expect (so 👍 )

Yessir!

If that specific thing isn’t working for you then it’s 100% a bug we need to fix

My issue was I couldn’t tell from the docs what the output of

buildAndPushImage().image()

does when it’s used in conjunction with

awsx/kubernetes/EKS

Inside a

Deployment/Pod

manifest for containers.

spec: {
                containers: [{
                    image, // **Use the image built above**
                }],

I know the string would be something like

<http://012345678901.dkr.ecr.us-west-2.amazonaws.com/my-repo-e2fe830:latest|012345678901.dkr.ecr.us-west-2.amazonaws.com/my-repo-e2fe830:latest>

Where parts of that is based on AWS meta-data like ID, region etc.

Yeah that metadata is from the state

:)

It’s part of the inputs / outputs of the image resource

Right, the issue here is if replica count changes and the image is generated as:

<http://amazonaws.com/my-repo-e2fe830:latest|amazonaws.com/my-repo-e2fe830:latest>

each time. The newer pods will run a new image if Docker failed to understand that there is no need for a new “image push” - that’s not on Pulumi though. That can happen for loads of reasons, e.g poorly made Dockerfile, etc.

Yeah :/ that’s the pitfalls of using latest I’m afraid - I always suggest using tag names specifically

Yep. It’s not an issue on master, but our staging and pr-environments.

Master has manually defined names (tags) from approved staging builds. But sometimes for a PR we want to test upping the replica count without redeploying a new image. Since we go through a CICD, it will build a new image, even though we just changed a replica count. I guess the real solution is using kubectl CLI to change just the replica count - that’s fine since we have access to pr environments via cli (not master or staging)

@broad-dog-22463 Thanks for explaining and being patient!

Any time!

Hello, I'm new to Pulumi but I have gotten beat down yesterday trying to deploy a helm chart. From the helm command I normally

helm -f values.yaml name /path/to/chart

I'd like to know how I can load a kubernetes yaml file and apply the configuration of

values.yaml

from

LocalChartOpts

. I found

kubernetes.yaml

but can't seem to get the proper values from E.G.

ConfigFile

I tried to for example set kubernetes config in a pulumi yaml file but due to the nested hierarchical yaml format I couldn't figure out how to load that configuration and try to apply via that route. Any pulumi kube experts in here that can help me reason about this, understand limitations, and sort this out?