Hi I updated to the 0.16.9 and my

pulumi update

is stuck in previewing update stage:

+-  └─ aws:secretsmanager:SecretVersion  integration_user_secret  replace     [diff: ~secretString]; completing deletion from previous update

-v doesn't seem to give me much, tips on how to probe into why it's hanging? I did a refresh and it completes successfully fwiw, but the freeze persists.

I'm running python 3.7.2

Hi! I am still evaluating pulumi as a replacement for terraform/k8s-with-python hybrid and I have a few questions that are related to our context and environment. I am not sure if this is a best place to ask questions about concepts and design.

1. Pulumi promotes stacks as a way to have a single pulumi project/program that covers multiple environments like dev, staging, prod etc. Does it work well in practice? In my case environments differ quite a lot (e.g. k8s zonal cluster in dev env and regional in prod, or standard vs private gke clusters: these different setups require mutually exclusive configuration options; some resources are needed in dev env but not in prod and vice versa). I’m concerned that it will end up in a very complex pulumi program with a lot of `if`s and mutually exclusive configuration entries. Would this be an issue?

2. In relation to the above question: I suspect my scenario might be quite common for others too - is there a way to work with pulumi without making usage of stacks explicit? I suspect I might need to go with single stack per pulumi project (with one pulumi project/stack per my actual environment) and a necessity to always think about stacks will be unnecessary distraction.

3. https://pulumi.io/reference/cd.html#branching-strategy-for-deployments suggests having git branch per stack and merging between branches to promote changes across environments (e.g. dev -> staging -> prod). I guess it would also be very tricky in my case but I would like to confirm how this is done in deployments like in my scenario.

4. We have an environment that is in scope for PCI DSS. Is app.pulumi.com PCI DSS compliant? It stores our infrastructure state which might include sensitive information like access tokens, passwords etc.

5. In our terraform code sometimes we need to resort to local-exec provider (e.g. to invoke

gcloud

to modify a resource with an option that is not yet supported by terraform google provider. Is there a counterpart of local-exec provider in pulumi?

6. I had scenarios where one of my terraform deployments had to be split into 2 or more deployments. Or I needed to move some resources from top-level resources into a module. I could use

terraform state mv|rm

and/or

terraform import

to achieve this. Is it supported in pulumi?

7. What level of granularity for stack outputs access permissions is available in pulumi? Is it possible to control it on an output-level or is it on stack level?

8. Will Google Cloud Storage bucket remote backend be supported in pulumi?

9. Is there an ETA on availability of BitBucket login to app.pulumi.com? I use bitbucket and it is a blocker for me to easily integrate with pulumi service.

I really appreciate all your answers and help @white-balloon-205 - thank you!

Actually I have the 10th question 🙂 - is it supported (and if yes - is there an example) to create Kubernetes custom resource definition (e.g. GKE BackendConfig: https://cloud.google.com/kubernetes-engine/docs/concepts/backendconfig)

Love the new UI for viewing plan diffs. 👏

Hi, I have a question about configuring kubernetes provider in pulumi - is it possible to set my own kubernetes provider instance as a default one so I don’t have to explicitly specify it as a provider for my kubernetes resources?

To be clear - I know I can specify config options for the default k8s provider via

pulumi config set kubernetes:kubeconfig

but in my case I create a gke container and create kubeconfig that I want to use - is it possible to pass that kubeconfig to the default kubernetes provider instance or create my own instance of kubernetes provider and replace the default one?

When working with Azure I have to call

az account get-access-token

every 30 minutes or so, otherwise login info is lost. As I understand, that's an issue on terraform side, but is there a workaround that pulumi could do? Like calling the command automatically.

@gifted-island-55702 also you can see more advice like this here: https://pulumi.io/quickstart/k8s-the-prod-way/index.html

Hello! 👋 I’m trying to automate our db migrations execution using Pulumi + Kubernetes. So far, i’ve tried to do it using two approaches: 1. Creating a k8s job that runs into completation, but both Pulumi and Kubernetes doesn’t have a resource lifecycle feature, like “delete this job after completion”. 2. By changing the image or name of the job. Since both fields are immutable, Pulumi should recreate the resource, but that’s not the case 😬.

Job.batch "api-migration-job-zdq5ov6o" is invalid: spec.template: Invalid value: [job spec]: field is immutable

I’ve tried to look at the

@pulumi/kubernetes

source code, but seems like it’s generated automatically. In this case, how do we fix that? 🤔

Hi again! I have some more questions as I have difficulties to grasp the concepts and how pulumi is designed. I had some comments earlier that it should be easier to work in scenarios where we have just one stack per pulumi program (e.g. by introducing an implicit stacks with an option to add more stacks if needed). After thinking about it more I came up with the questions below: 1. What’s the difference between pulumi program and pulumi project? Are they the same thing? Is it possible to have more than one pulumi program in one pulumi project? If yes, when is it useful? 2. It seems that stacks are the most important entities in pulumi - they keep state of resources from a specific pulumi program. But they are “owned” by a pulumi project, at least this is how they are shown in app.pulumi.com - and still their names have to be unique in my whole account/organization. That is really misleading for me. If they are part/owned by a pulumi project, shouldn’t their names be scoped to pulumi project instead? 3. If stacks are the most important entities in pulumi (they are in my opinion), shouldn’t they be the top level resource in an account organization and their pulumi program/project be just a metadata by which we could be able to group them if we need to instead? 4. Maybe pulumi projects should be just the pulumi program concept (local to the runtime environment where they are executed) and should not be the top level entities in app.pulumi.com? Maybe we should have just stacks that are results of running a pulumi program and the main link between a pulumi program and a stack should be local to the program (with just a metadata information like a label or a tag in app.pulumi.com like the idea in question 3)?

Each

Pulumi.yaml

file is a project. That project executes some program to do a deployment. See https://pulumi.io/reference/project.html. There can be multiple instances of a single project deployed at a time. This is often the case for development/test/production, or for separate regions, etc. But some projects will just have a single instance, at least at some moment in time. Each instance of a project is a stack. See https://pulumi.io/reference/stack.html. Today, the identity of a stack is

<org>/<stack>

and the project is just metadata (tags) attached to it. That project metadata is used in the default rendering on the

Projects

page at app.pulumi.com and to filter

pulumi stack ls

CLI commands when in a project folder. But otherwise is just metadata. Only stacks exist. We are moving to make the project part of the identity as

<org>/<project>/<stack>

. As you note in the thread, this will make it natural to think of having a

default

stack for a project in cases where you know you will only have one.

Thank you @white-balloon-205 - that makes it clear for me.

Yep , which is the difference between

pulumi/actions

and

pulumi/pulumi

both are in dockerhub , looks like both are oficial https://hub.docker.com/r/pulumi/actions and https://hub.docker.com/r/pulumi/pulumi , no description into the images, i'm using them (just for poc) , and pulumi inside is a little bit old.

I’m getting this issue intermittently when building docker containers on circleci’s remote docker socket

pulumi:pulumi:Stack XXXXXXXXX-images  error: transport is closing

Hello Pulumi community! I'm heading up a team that's decided to give Pulumi a try for a rather substantial CI/CD architecture - more on that to come, I'm sure. For now we're just taking Pulumi for a spin and testing some of our ideas out, and we're noticing something peculiar that we haven't come across in any of the docs. When I create a resource such as this:

const resourceGroup =
    new azure.core.ResourceGroup(
        `retrospect-${envName}-infra`,
        {
            location: "westeurope"
        }
    );

Pulumi adds an auto-generated suffix to the name, like so:

retrospect-dev-infra5bf12d3a

Firstly, why is it doing this, and secondly, how can we override this behavior? We'd like to avoid that because we'll be encoding project and stack names into our resource names where necessary, so the random suffix just makes things more cluttered..

Hello everyone ! First a happy new year to all of you. And wishing to accomplish great things with pulumi to @echoing-match-29901 for this new year to come. I already asked something similar a few days ago but we didn’t really tackle the question. I’m wondering how to implement some sort of user’s CRD component with Pulumi to manage my database users (ie. postgreSQL) easily. How do you guys do such things ? I can manage the permissions with a template of the

pg_hba.conf

but to create/delete users I need to run a command directly on the master pod.

Hello Pulumi community! @echoing-match-29901 I'm trying to use Pulumi with Python SDK and I want to deploy a helm chart with it but I'm not able to find a module. Do we have a library or a module in python which is able to do this or not yet ?

The

pulumi.Config

object constructor states that :

[…] For example, a bag whose name is pulumi:foo, with keys a, b, and c, is entirely separate from a bag whose name is pulumi:bar with the same simple key names.

Each key has a fully qualified names, such as pulumi:foo:a, ..., and pulumi:bar:a, respectively.

It gives as an example that a config could be named

pulumi:foo

which gives a possible fully qualified key

pulumi:foo:a

. Or if I try to define a config bag as such, I get an error :

error: invalid configuration key: could not parse foo:bar:ber as a configuration key (configuration keys should be of the form `<namespace>:<name>`)

It seems to refuse a

:

in the

Config

name