Stack (...) is in CREATE_FAILED state and can not be updated.

[belfz]

Got this while trying to deploy the simple function (first example from dawson's docs):

 ↓ running pre-deploy hook [skipped]
 ✔ validating configuration
 ↓ running pre-deploy hook [skipped]
 ✔ validating configuration
 ✔ checking prerequisites
 ✔ creating bundle
 ✔ generating template
 ↓ removing stack policy [skipped]
 ✖ requesting changeset
   → Stack:arn:aws:cloudformation:us-west-2:125826905630:stack/dawson-tutorialDefault/d8434070-0fdb-11e7-b5d8-50a68a201256 is in CREATE_FAILED state and can not …
   waiting for stack update to complete
   setting stack policy
   running post-deploy hook
   uploading assets
dawson internal error: Stack:arn:aws:cloudformation:us-west-2:125826905630:stack/dawson-tutorialDefault/d8434070-0fdb-11e7-b5d8-50a68a201256 is in CREATE_FAILED s
tate and can not be updated.
ValidationError: Stack:arn:aws:cloudformation:us-west-2:125826905630:stack/dawson-tutorialDefault/d8434070-0fdb-11e7-b5d8-50a68a201256 is in CREATE_FAILED state a
nd can not be updated.
    at Request.extractError (/usr/local/lib/node_modules/dawson/node_modules/aws-sdk/lib/protocol/query.js:47:29)
    at Request.callListeners (/usr/local/lib/node_modules/dawson/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
    at Request.emit (/usr/local/lib/node_modules/dawson/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/usr/local/lib/node_modules/dawson/node_modules/aws-sdk/lib/request.js:673:14)
    at Request.transition (/usr/local/lib/node_modules/dawson/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/usr/local/lib/node_modules/dawson/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /usr/local/lib/node_modules/dawson/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/usr/local/lib/node_modules/dawson/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/usr/local/lib/node_modules/dawson/node_modules/aws-sdk/lib/request.js:675:12)
    at Request.callListeners (/usr/local/lib/node_modules/dawson/node_modules/aws-sdk/lib/sequential_executor.js:115:18)
Please report this bug: https://github.com/dawson-org/dawson-cli/issues

[brandoncorbin]

I'm seeing this error too.

Mac 10.11.6 Node v6.10.1

[rakistner]

I am experiencing the same issue, even doing the example deploy from the docs. Dawson 0.23.3 Node v 7.6 OSX 10.10.5

[sayjava]

Same here, sa,e problem

[rakistner]

It seems this is an IAM roles issue. I was unable to successfully use the cli with anything other than giving a user the AdministratorAccess role. PowerUserAccess and individual policy attachments for each service in the build (such as LambdaInvokeFullAccess) did not work. The easy fix is to create a non-admin user with admin access, but obviously in the long term this is not ideal. Have not identified where in the source code this might be restricted yet.

[lusentis]

Ok, I'm sorry for the issues you're experiencing. I thought this was related to an issue we're having internally: on 23rd March since early morning (GMT+1) stack creation and updates were failing due to an internal AWS issue related to IAM Policies. I initially thought that such issue was related to yours, probably incorrectly. The AWS internal issue now seems to be fixed and deploys are working again as expected.

Unfortunately, errors which happen during the Create step are not as informative as errors happening during a Stack Update operation (we'll fix).

@rakistner the CLI uses CloudFormation to create resources, including, for example, IAM Roles. CloudFormation will then need the permission to call operations such as IAM::CreateRole etc. CloudFormation inherits the permissions of the user executing the UpdateStack operation. The easiest way to ensure that every update will succeed is to use an AdministratorAccess policy attached to the user which is running the dawson command. (You won't find any call to IAM::CreateRole in dawson's code, because this operation is called internally by CloudFormation.)

Quoting an HN comment of mine:

dawson will soon switch to using an AWS CloudFormation Service Role, which allows us to require users to grant fine-grained permissions. We will then provide a copy-pasteable Policy for users to set, and update the documentation accordingly. Currently, since CloudFormations runs with the CLI user's AWS Credentials, such user needs to be granted the permission to do every action, including, for example, managing DynamoDB Tables, S3 Buckets etc... Also, imagine you're adding an S3 Bucket as a custom resource to your app. dawson will create such S3 Bucket using CloudFormation; CloudFormation needs to be run by a user with S3::CreateBucket permission. This applies for each resource managed by dawson/CloudFormation. NONE of your App's code will run using such "AdministratorAccess" policies. Each function will run in its own IAM::Role with limited permissions defined by the developer. The AdministratorAccess is currently required only for the CLI but, as said in my previous comment, we'll eventually move to using a Service Role and providing a more restrictive policy.

Tracking in #159, this will be our top priority after merging Python support later this week.

Documentation for the current version is here: https://dawson.sh/docs.html#01-obtaining-aws-credentials-short-version, and says to use an AdministratorAccess policy. If you missed this point or think it should be written more clearly, please let us know!

[lusentis]

I'd appreciate knowing if you're able to perform a deploy in these days (no dawson update was published to npm since the issue appeared to be internal to AWS). If not, could you please provide the error message that the AWS CloudFormation Console displays?

Thanks for your feedback

[rakistner]

I am able to deploy successfully today. I did miss that step in the docs, but it's definitely not because it's not written clearly haha. The enhancement from your comment sounds like what I expected to happen. Thanks for getting back to us so quickly!

[lusentis]

Thank you!

I did miss that step in the docs, but it's definitely not because it's not written clearly haha

It's always system's fault ;)

We'll for sure improve the error message, and maybe attempt to validate permissions before running. I'm leaving this issue open.

Thanks for your feedback,

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lusentis]

I'm closing this issue since, at this point, we can confirm it was an AWS internal error. Regarding the AdministratorAccess comment, I'm resuming work on #159.