https://pulumi.com logo
Docs
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
  • s

    stocky-spoon-28903

    06/22/2018, 6:02 PM
    If there’s a better place to report this kind of thing, let me know, just throwing them in here as I find them for now
  • m

    microscopic-pilot-97530

    06/22/2018, 6:05 PM
    Letting us know here is perfect. Thanks!
    w
    • 2
    • 1
  • a

    average-lifeguard-69220

    06/22/2018, 7:50 PM
    How do I fix the state of Pulumi - An EC2 instance was manually deleted in the AWS Console, then removed from the Pulumi index.js file... however the plan apply fails because it can't find the instance
  • a

    average-lifeguard-69220

    06/22/2018, 7:51 PM
    ^ note: i realize the delete should've been managed by pulumi
  • c

    colossal-beach-47527

    06/22/2018, 7:52 PM
    @average-lifeguard-69220 I believe running
    pulumi refresh
    will correct this. Refresh essentially trues up your resource checkpoint file with reality. If that doesn’t work, then you can
    pulumi stack export > checkpoint.json
    and manually remove the reference to the EC2 instance. Then run
    pulumi stack import < checkpoint.json
    .
  • a

    average-lifeguard-69220

    06/22/2018, 7:55 PM
    hmmm - think I may not have migrated properly...
    $ pulumi refresh
    Please choose a stack, or create a new one: myapp
    warning: could not detect GitHub project information: could not read origin information: remote not found
    Previewing refresh of stack 'myapp'
    panic: runtime error: invalid memory address or nil pointer dereference
    [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xabc009]
    
    goroutine 61 [running]:
    <http://github.com/pulumi/pulumi/pkg/backend/cloud.(*tokenSource).GetToken(...)|github.com/pulumi/pulumi/pkg/backend/cloud.(*tokenSource).GetToken(...)>
    	/home/travis/gopath/src/github.com/pulumi/pulumi/pkg/backend/cloud/state.go:87
    <http://github.com/pulumi/pulumi/pkg/backend/cloud.(*cloudSnapshotPersister).Save|github.com/pulumi/pulumi/pkg/backend/cloud.(*cloudSnapshotPersister).Save>(0xc420327c80, 0xc42012a620, 0xc420078f88, 0xc4203b5c78)
    	/home/travis/gopath/src/github.com/pulumi/pulumi/pkg/backend/cloud/snapshot.go:32 +0x79
    <http://github.com/pulumi/pulumi/pkg/backend.(*SnapshotManager).mutate.func1()|github.com/pulumi/pulumi/pkg/backend.(*SnapshotManager).mutate.func1()>
    	/home/travis/gopath/src/github.com/pulumi/pulumi/pkg/backend/snapshot.go:80 +0x6d
    <http://github.com/pulumi/pulumi/pkg/backend.NewSnapshotManager.func1(0xc4202db680)|github.com/pulumi/pulumi/pkg/backend.NewSnapshotManager.func1(0xc4202db680)>
    	/home/travis/gopath/src/github.com/pulumi/pulumi/pkg/backend/snapshot.go:319 +0x49
    created by <http://github.com/pulumi/pulumi/pkg/backend.NewSnapshotManager|github.com/pulumi/pulumi/pkg/backend.NewSnapshotManager>
    	/home/travis/gopath/src/github.com/pulumi/pulumi/pkg/backend/snapshot.go:317 +0x114
  • a

    average-lifeguard-69220

    06/22/2018, 7:56 PM
    $ pulumi version
    v0.12.2
  • c

    colossal-beach-47527

    06/22/2018, 7:57 PM
    Well that looks like a bug, but it might be fixed in a newer version of the CLI. I know we made some fixes to
    refresh
    recently. I’d be curious if it repros with the newer CLI (v0.14). But in the mean time, does
    stack export
    and
    stack import
    work?
  • c

    colossal-beach-47527

    06/22/2018, 7:57 PM
    (In the checkpoint JSON file, search for a resource with “ec2” in the URN or name and just delete it from the file.)
  • a

    average-lifeguard-69220

    06/22/2018, 7:57 PM
    the export only results in the export outputs
    c
    • 2
    • 9
  • a

    average-lifeguard-69220

    06/22/2018, 7:57 PM
    doesn't have any of the actual resources
  • c

    colossal-beach-47527

    06/22/2018, 8:01 PM
    Interesting. So if you run
    pulumi update
    again, and remove references to the ec2 instance in the code, then you shouldn’t have any problem? Since pulumi.com doesn’t have any EC2 instances associated with your stack?
  • t

    tall-librarian-49374

    06/22/2018, 9:31 PM
    I've posted a blog "Programmable Cloud: Provisioning Azure App Service with Pulumi": https://mikhail.io/2018/06/programmable-cloud-provisioning-azure-app-service-with-pulumi/ Any comments are welcome!
    👍 3
    ❤️ 4
    💯 4
    a
    • 2
    • 2
  • b

    big-soccer-75859

    06/23/2018, 3:27 PM
    Is there a way to do API Gateway Authorizers?
  • b

    big-soccer-75859

    06/23/2018, 3:32 PM
    Just having a think and perhaps I could go the way of middleware instead
  • b

    big-soccer-75859

    06/23/2018, 5:21 PM
    I don't appear to be able to import node modules and use them in RouteHandlers. Getting errors like this one
  • b

    big-soccer-75859

    06/23/2018, 5:21 PM
    Diagnostics:
      global: global
        error: Error serializing '(ev, ctx, cb) => { let body; ...': api.js(234,106)
    
        '(ev, ctx, cb) => { let body; ...': api.js(234,106): captured
          variable 'route' which indirectly referenced
            '(req, res, next) => { lodash.map([1, ...': index.js(14,25): which captured
              module './node_modules\\lodash\\lodash.js' which indirectly referenced
                function 'lodash': lodash.js(1662,19): which could not be serialized because
                  the function form was not understood.
    
        Function code:
    
    
        Capturing modules can sometimes cause problems.
        Consider using import('./node_modules\\lodash\\lodash.js') or require('./node_modules\\lodash\\lodash.js') inside '(req, res, next) => { lodash.map([1, ...': index.js(14,25)
    
        error: an unhandled error occurred: Program exited with non-zero exit code: 1
  • b

    big-soccer-75859

    06/23/2018, 5:21 PM
    any ideas?
  • m

    microscopic-florist-22719

    06/23/2018, 5:41 PM
    If you’re not already doing so, you’ll need to import the module inside the body of the handler. In typescript, this is the
    await import
    syntax.
    b
    w
    • 3
    • 10
  • m

    microscopic-florist-22719

    06/23/2018, 5:41 PM
    (cc @lemon-spoon-91807 @white-balloon-205 @incalculable-sundown-82514 )
  • i

    incalculable-sundown-82514

    06/23/2018, 5:44 PM
    Yeah, that’s correct. Though I think we have a bug here in that there’s a function in lodash we don’t understand. Can you post the function that’s at line 1662 in lodash.js?
  • i

    incalculable-sundown-82514

    06/23/2018, 5:45 PM
    In general you can always await import or require things inside your lambda and it should be fine
  • s

    stocky-spoon-28903

    06/23/2018, 5:48 PM
    In the Go SDK, all of the acronyms are downcased (e.g.
    Vpc
    ,
    Ec2
    ) - the idiomatic thing in Go is to spell acronyms out in all caps. Was this a conscious decision to match other SDKs or just an artefact of how the provider SDK gets generated?
    w
    • 2
    • 2
  • s

    stocky-spoon-28903

    06/23/2018, 10:50 PM
    Another comment on them: the data source response objects are super raw:
  • s

    stocky-spoon-28903

    06/23/2018, 10:51 PM
    azs, err := aws.LookupAvailabilityZones(ctx, &aws.GetAvailabilityZonesArgs{
    		State: "available",
    	})
    	if err != nil {
    		return nil, errors.Wrap(err, "error looking up availability zones")
    	}
    
        // use: len(azs.Names.([]string)) => panic because it's []interface{}
  • s

    stocky-spoon-28903

    06/23/2018, 10:51 PM
    Probably these should be adjusted to be real types?
  • s

    stocky-spoon-28903

    06/23/2018, 11:00 PM
    s/real/useful/ - or at least documented as to what they will be, because the casting right now is just guesswork until runtime
  • w

    white-balloon-205

    06/23/2018, 11:03 PM
    @stocky-spoon-28903 Yeah - this is related to the issue being discussed in https://github.com/pulumi/pulumi-aws/issues/248. We'll need to introduce something stronger-typed that
    interface{}
    as the element type of input/outputs for all resource and data source properties to make these APIs more natural to use.
  • s

    stocky-spoon-28903

    06/23/2018, 11:11 PM
    I’ll subscribe to that issue, I don’t have any sensible suggestions over what is already listed there.
  • s

    stocky-spoon-28903

    06/23/2018, 11:11 PM
    I think I may go back to Typescript for now
    w
    • 2
    • 2
Powered by Linen
Title
s

stocky-spoon-28903

06/23/2018, 11:11 PM
I think I may go back to Typescript for now
w

white-balloon-205

06/23/2018, 11:15 PM
Just as a note - the Go support is very new - so great to get feedback on it, but fair warning that it's likely to be in more raw state than JS/TS (or Python) 🙂. We'll definitely be making progress on some of these issues in the coming days/weeks!
s

stocky-spoon-28903

06/24/2018, 12:20 AM
Yup, definitely appreciated. I’ll keep playing with it but I’m trying to deliver an actual thing for someone at the moment so I’ll go back to the “stable” path 😉
View count: 1