Service will not redeploy correctly if new functions are added above old ones

[wedgybo]

Serverless Framework Version: v1.0.0-alpha.2

Operating System: OSX

Expected Behavior:

When I add a new function to the serverless.yaml file. The service is redeployed correctly

Actual Behavior:

If the new function is created above an existing functions the deployment fails and is rolled back.

Noticed this when adding a new one as I like to keep the functions in order alphabetically

Stack-Trace (Optional):

Serverless Error ---------------------------------------

 An error occurred while provisioning your cloudformation:
 The following resource(s) failed to create: [ResourceApigEvent1].

Stack Trace --------------------------------------------

ServerlessError: An error occurred while provisioning your cloudformation: The following resource(s) failed to create: [ResourceApigEvent1].
at /Users/jsutherland/Source/serverless/lib/plugins/aws/deploy/lib/updateStack.js:56:33
at tryCatcher (/Users/jsutherland/Source/serverless/node_modules/bluebird/js/release/util.js:16:23)
at Promise._settlePromiseFromHandler (/Users/jsutherland/Source/serverless/node_modules/bluebird/js/release/promise.js:504:31)
at Promise._settlePromise (/Users/jsutherland/Source/serverless/node_modules/bluebird/js/release/promise.js:561:18)
at Promise._settlePromise0 (/Users/jsutherland/Source/serverless/node_modules/bluebird/js/release/promise.js:606:10)
at Promise._settlePromises (/Users/jsutherland/Source/serverless/node_modules/bluebird/js/release/promise.js:685:18)
at Async._drainQueue (/Users/jsutherland/Source/serverless/node_modules/bluebird/js/release/async.js:138:16)
at Async._drainQueues (/Users/jsutherland/Source/serverless/node_modules/bluebird/js/release/async.js:148:10)
at Immediate.Async.drainQueues as _onImmediate
at processImmediate as _immediateCallback

Get Support --------------------------------------------
Docs: v1.docs.serverless.com
Bugs: github.com/serverless/serverless/issues

[eahefnawy]

Intersting!!!! Nice catch! So if I understood this correctly, the order of the functions defined in serverless.yml matters?

Hmmm yeah I guess that makes sense because we currently map the endpoints/resources according to index.

[wedgybo]

Yea basically you always need to add to the bottom. Yup, should look at mapping them to the function name in some way so they can be targeted by that rather than index.

After having done a fair bit of investigation, and learning about cloudformation, for #1684 there are a few issues in this space with the way the current updates are happening.

For now the best thing is to remove / deploy when you're making changes as a lot of stuff currently won't get updated.

Exciting stuff though. Really liking the new v1.0 and I think it will be awesome once the bugs are ironed out!

[svdgraaf]

@eahefnawy I was wondering, currently, the FunctionName is set on the CloudFormation Lambda objects. Is there a specific reason why that one is set? If we don't set one, CF will generate one (based on the Resourced Id). We are then a lot more flexible with renaming and changing the Lambda functions with a deploy on the fly:

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html#cfn-lambda-function-functionname

If you specify a name, you cannot do updates that require this resource to be replaced. You can still do updates that require no or some interruption. If you must replace the resource, specify a new name.

This would just replace all the methods correctly, without any error.

I just encountered the same issue. I changed my runtime, which would have resulted in replacement of all the Lambda functions, but that's not possible because of the set name, so I got a Rollback as well.

I see @wedgybo already fixed the removal of the index on the functions (see the commit above), but that won't fix the replacement issue we would still have because of the set FunctionName on the Lambda resource. If we want to fix that, I could create a PR for that :)

[wedgybo]

@svdgraaf What sort of updates are failing. Sorry I'm quite new to this and a bit lost. My guess is it's set to make it easy to identify. I've not come across this issue when redeploying and the like so I'd like to understand more.

Basically any change to the lambda config and we have to delete and recreate rather than update?

[wedgybo]

Sorry read the docs and it clicked this time. So the only change that requires a replacement is a change to the runtime.

I'm not sure I'd want to lose readability for something that won't change that often over the course of a service. The alternative would be to add the runtime into the name so it would be unique?

[svdgraaf]

@wedgybo well, the runtime is not the only reason a Lambda function can be replaced (eg: adding vpc config etc will do that too). The 'problem' is that currently the lambda resources are locked in place, and can only be replace by renaming the Resource Id's in the CloudFormation template (which isn't very handy to do currently).

If there is no particular reason to set the function name, it would be a better to remove the property, and have CloudFormation generate a name.

The "problem" is here: https://github.com/serverless/serverless/blob/v1.0/lib/plugins/aws/deploy/compile/functions/index.js#L31

But I can't find the reason why it's there.

Ninja-edit: you're right, the runtime is currently the only reason for it to be replaced. Hmmm, so perhaps not a real issue, no :)

Another ninja-edit: Never mind, I don't think it's an issue indeed. Sorry for all the mess 😄

[eahefnawy]

Resolved with this PR