the above might be related to my question: I’ve got a Pulumi script that now can build a copy of my whole environment quite nicely, but my production environment is still… ahem artisanal… the script builds something that should be identical to this environment, but i’m sure I’ve missed something. I’d like to get my production env under control via pulumi, but 1) i don’t want to have excessive downtime (a little is fine, but i’m particularly worried about DNS/MX etc) and 2) i don’t want to have to rebuild my production RDS instance - Is there a good strategy from migrating from a bespoke deployment to Pulumi in this situation?

Using the below code;

const bucket = new aws.s3.Bucket("my-bucket", {
    acl: "public-read"
});

the result was a bucket named: my-bucket-e48aec4 The following code:

const storage = new azure.storage.Account("divgopulumi", {
    location: 'eastus',
    resourceGroupName: 'MyRG',
    accountReplicationType: "LRS",
    accountKind: "StorageV2",
    accessTier: "Cool",
    accountTier: "Standard",
    customDomain: {
        name: "<http://files.mydomain.com|files.mydomain.com>",
        useSubdomain: true
    }
})

resulted in a storageAccount named: divgopulumic91925bb My question is: how do I generate these objects without the trailing random characters?

The system auto-names resources to avoid conflicts between stacks. But, you may override this by setting the name explicitly:

const bucket = new aws.s3.Bucket("my-bucket", {
    bucket: "my-bucket",
    ... as before ...
});

and

const storage = new azure.storage.Account("divgopulumi", {
    name: "divgopulumi",
    ...
});

Most of the time, the property is called

name

, however unfortunately the S3 Bucket type is the odd duck here, with

bucket

. We've been discussing what to do here, such as a global flag like

--no-auto-names

as we know not everybody wants the name mangling, and it can be tedious to override this on every single resource. Also, Azure isn't as bad as AWS, since names only need to be unique within a ResourceGroup. Feedback definitely appreciated on the topic.

@big-piano-35669 - Thanks for the quick reply. Confirmed that adding those 2 properties yielded the results I was looking for. Thank you again for the quick reply.

how does pulumi know what is the active stack for a dir? Is this stored locally with a link between the dir name and the current active stack? I notice If I rename the project folder the active stack is reset to none

Just a guess: in your home directory, there should be a .pulumi subdirectory

within there a dir workspaces, and some json configuration files

@best-tent-29186 @gray-city-50684 Yes - that's right - this association is stored in

~/.pulumi/workspaces

. You can update the active stack with

pulumi stack select

.

I'm trying to figure out, how to automate an AKS cluster creation + populate it with some deployments. I have two questions by reading the docs / examples (not yet trying it):

1., Can I create the Service Principal required for the AKS cluster (would be equivalent to Terraform's azuread_application + azurerm_azuread_service_principal)

2., Once I have the AKS cluster, can I somehow use it with the Pulumi Kubernetes provider directly?

In fact, both of these will be (newly) possible with the

0.15.0

release which we expect to release today (currently

0.15.0-rc2

is published and being tested). On 1. this was added with https://github.com/pulumi/pulumi-azure/pull/86. I haven't used this yet myself, but the two Terraform Azure Provider resources you note are now available in Pulumi. On 2. we've added support for "1st class providers" in

0.15.0

which allows you to do

new kubernetes.Provider({ kubeconfig: ..., context: ... })

to create a new Kubernetes provider configured with a kubeconfig that was potentially computed as a result of other operations. We'll have an example of this exact use case (AKS + Kubernetes deployments) published along with the release later today. You can see a simple example here: https://github.com/pulumi/pulumi-kubernetes/blob/a2ba053df34ecb980c8d218a47f6208cd7e7282f/examples/provider/index.ts

Great, thanks!

I've just deleted resources, then the stack, and have created a new stack, but now when I preview or update I get a go panic with

fatal: [500] Internal Server Error

unless someone knows the issue and has a workaround, I'll wait for 0.15.0 and if I can repro I'll open an issue

" release today" is that a Seattle day? (GMT-7)

@helpful-vegetable-35581 Yes, we're quoting PST times 🙂 ... we may still have an issue or two to track down, however, we're really close

Looking forward to it 🙂

This weekend we updated our documentation to describe how to incorporate Pulumi into your Travis CI. This is how we manage updating our own services, mapping Stacks to repo branches. If you have feedback, or need help adding Pulumi to some other CI service please let me know. https://pulumi.io/reference/cd-travis.html

Maybe I can write something about Gitlab CI when I'm done with my Pulumi migration.

If it helps 🤔

Spin Up Colada is back on Wednesday. Pulumi is packed to the gunwales with new features, and @white-balloon-205 will be covering it all at 11am PDT, 15th August. Join us!

Are there plans (or anything in place currently) for using pulumi without the github dependency? All our code is on an internal gerrit server and we don't use github at all which means can't really use the pulumi cloud service. I'm experimenting with doing it via the local backend and maybe nfs shares. Thought I'd raise it maybe there's plans or a better way?

Something that would be nice is a stack-wide “name prefix” that gets applied to automatically generated names (e.g. for things like

prod-

or whatever)

For those who aren't yet in #announcements - sharing this here as well: https://pulumi-community.slack.com/archives/CB36DSVSA/p1534293689000100

The 0.15 release post from @white-balloon-205 is live: http://blog.pulumi.com/announcing-pulumi-0.15-kubernetes-cicd-openstack-and-more

Along with the Twitter mega thread: https://twitter.com/PulumiCorp/status/1029788783854510080

And you can join us right now at:

Thanks to everyone who contributed - awesome work!

(and yeah, we'