https://pulumi.com logo
Join the conversationJoin Slack
Channels
announcements
automation-api
aws
azure
blog-posts
built-with-pulumi
cloudengineering
cloudengineering-support
content-share
contribex
contribute
docs
dotnet
finops
general
getting-started
gitlab
golang
google-cloud
hackathon-03-19-2020
hacktoberfest
install
java
jobs
kubernetes
learn-pulumi-events
linen
localstack
multi-language-hackathon
office-hours
oracle-cloud-infrastructure
plugin-framework
pulumi-cdk
pulumi-crosscode
pulumi-deployments
pulumi-kubernetes-operator
pulumi-service
pulumiverse
python
registry
status
testingtesting123
testingtesting321
typescript
welcome
workshops
yaml
Powered by Linen
general
  • b

    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).
  • s

    stocky-spoon-28903

    06/20/2018, 4:01 PM
    Ok, that’s what I thought lol
  • s

    stocky-spoon-28903

    06/20/2018, 4:01 PM
    Yes, the Kubernetes terraform provider is… janky at best
  • b

    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.
  • b

    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
  • s

    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’
  • b

    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.
  • b

    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?
  • b

    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.
  • b

    blue-answer-29496

    06/20/2018, 4:08 PM
    That’s what I thought. Pretty interesting.
  • s

    stocky-spoon-28903

    06/20/2018, 4:08 PM
    Have you considered a higher level integration than fork/exec for something like Packer?
  • s

    stocky-spoon-28903

    06/20/2018, 4:08 PM
    In the case where you want AMIs rather than containers?
  • s

    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
  • w

    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.
  • s

    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
  • w

    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.
    • 1
    • 2
  • s

    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
  • w

    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.
  • s

    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
  • s

    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
  • b

    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.
  • b

    blue-answer-29496

    06/20/2018, 4:27 PM
    Seems like I might need to import the Output object from pulumi
  • b

    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
  • w

    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.
    • 1
    • 2
  • b

    blue-answer-29496

    06/20/2018, 4:34 PM
    Ok
  • w

    white-balloon-205

    06/20/2018, 4:35 PM
    Oh - sorry - I meant remove
    "declaration": true
    . Fixed in original message above.
  • b

    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.
  • b

    blue-answer-29496

    06/20/2018, 4:36 PM
    and kind of sucks adding the extra compile step before running.
  • w

    white-balloon-205

    06/20/2018, 4:36 PM
    TypeScript can still be quite handy, especially for error checking and parameter validation.
  • b

    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.
Powered by Linen
Title
b

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.
View count: 2