pulumi-community #general

general

bitter-oil-46081

06/20/2018, 4:00 PM

Our general bridge framework: https://github.com/pulumi/pulumi-terraform. This also generates the strongly typed API for the languages we support. You can, of course, code directly to our provider interface (which is how our Kubernetes provider works).

stocky-spoon-28903

06/20/2018, 4:01 PM

Ok, that’s what I thought lol

stocky-spoon-28903

06/20/2018, 4:01 PM

Yes, the Kubernetes terraform provider is… janky at best

blue-answer-29496

06/20/2018, 4:03 PM

It’s very interesting and maybe a little confusing to me how Pulumi is blurring the lines between infrastructure, CI and your app code.

blue-answer-29496

06/20/2018, 4:04 PM

Are you guys thinking that we could just put something like this: https://github.com/pulumi/examples/blob/master/cloud-ts-voting-app/index.ts

stocky-spoon-28903

06/20/2018, 4:04 PM

I’ve so far ignored the higher level bits and focused on it as a ‘better Terraform core’

bitter-oil-46081

06/20/2018, 4:04 PM

If you look at the history of the pulumi-kubernetes repository you’ll see we started by using the Terraform provider but moved away from it in favor of a direct implementation since it also had some issues we didn’t like.

blue-answer-29496

06/20/2018, 4:05 PM

into our build and that would automatically both build and deploy an updated version of the app?

bitter-oil-46081

06/20/2018, 4:07 PM

We use pulumi to manage all of the infrastructure for our web service. So our Travis CI is more or less just a call to “pulumi update”. It builds all the containers and such for us and then does the updates.

blue-answer-29496

06/20/2018, 4:08 PM

That’s what I thought. Pretty interesting.

stocky-spoon-28903

06/20/2018, 4:08 PM

Have you considered a higher level integration than fork/exec for something like Packer?

stocky-spoon-28903

06/20/2018, 4:08 PM

In the case where you want AMIs rather than containers?

stocky-spoon-28903

06/20/2018, 4:09 PM

At one point I built a Terraform provider for it, which worked and at least put AMI builds under a single command but it was pretty rough underneath and never released

white-balloon-205

06/20/2018, 4:11 PM

Re: Packer - yes, we've talked about it. Would love to do something here. If you want to open an issue in pulumi/pulumi with some notes on how you think we should approach this - that would be great.

stocky-spoon-28903

06/20/2018, 4:11 PM

I’ll have a think about how it might fit into this model, I need to investigate how the engine works in a bit more detail to know what is feasible

white-balloon-205

06/20/2018, 4:12 PM

Note that the "fork/exec" style is also not an entirely bad way to do this, at least initially. In fact, our container build support for a similar scenario ultimately bottoms out on

docker

CLI invocations.

stocky-spoon-28903

06/20/2018, 4:12 PM

I think a similar model could be taken whereby the build could be defined as actual code, and a model generated out that goes to a packer bridge for each of the steps

white-balloon-205

06/20/2018, 4:14 PM

Exactly. The nice thing about being able to define higher level components is you can hide these low level details of how you interact with Packer (or Docker) behind a simple interface for users.

stocky-spoon-28903

06/20/2018, 4:14 PM

Right - Packer does that to an extent, and perhaps some of that model could be reused

stocky-spoon-28903

06/20/2018, 4:15 PM

FWIW the internals of packer are “interesting” and it might not be directly usable in any case

blue-answer-29496

06/20/2018, 4:27 PM

Any idea why I’m getting this error when trying to use the vote frontend sample? index.ts(46,12): error TS4023: Exported variable ‘frontendURL’ has or is using name ‘Output’ from external module “/Users/ejsmith/pulumi-test/node_modules/@pulumi/pulumi/resource” but cannot be named.

blue-answer-29496

06/20/2018, 4:27 PM

Seems like I might need to import the Output object from pulumi

blue-answer-29496

06/20/2018, 4:28 PM

Hmm… yep… that’s weird. Had to add

import { Output } from "@pulumi/pulumi";

to the top of the file

white-balloon-205

06/20/2018, 4:33 PM

This is a slightly unfortunate TypeScript thing. The best way to avoid this is to remove the

"declaration": true

line from

tsconfig.json

. We plan to remove this from all examples and templates to avoid this.

blue-answer-29496

06/20/2018, 4:34 PM

white-balloon-205

06/20/2018, 4:35 PM

Oh - sorry - I meant remove

"declaration": true

. Fixed in original message above.

blue-answer-29496

06/20/2018, 4:36 PM

I guess there isn’t much need to use TypeScript for these files since vscode will still give all of the intellisense and checking from the typescript definitions of the packages I’m referencing and the app code doesn’t really need typings.

blue-answer-29496

06/20/2018, 4:36 PM

and kind of sucks adding the extra compile step before running.

white-balloon-205

06/20/2018, 4:36 PM

TypeScript can still be quite handy, especially for error checking and parameter validation.

blue-answer-29496

06/20/2018, 4:37 PM

It’s my understanding that vscode would still output the exact same errors for .js files because it knows all the type information from the referenced packages and those types would flow through my script.