[proposal] Add support for timeout, memory size, and tagging on Lambda functions

[kyleknap]

Abstract

Add support for various granular configuration options in the chalice config.json. This will entail adding timeout, memory_size, and tags to the ``config.json` to support respectively the timeout of a lambda function, the memory size of a lambda function, and the tags on a lambda function.

Motivation

The feature has been requested in the following issues:

• Add support for optional deployment options #192
• Add support for more lambda options in config.json and allow config changes between deploys #195

Specifically, users would want to configure:

• Timeout:

  • It is typically advised to set a timeout that is around the maximum expected time for your
    code to run to cut down costs if the execution is running longer than it should be.
  • The default is set to 60. Some users may want their lambda function to be able to ran longer
    than 60 seconds.

• Memory Size:

  • The default is set to 128 MB. If your application requires more, a user would need to increase
    that value.
  • AWS Lambda uses the memory size to infer the amount of CPU allocated to your function. So
    a user may want to increase memory size to increase the amount of CPU allocated.

• Tags:

  • It provides an easy way for users to track and identify the various AWS resources they own.

Interface

config.json

The following keys will be allowed in the config.json

• timeout: This is an integer representing the timeout in seconds for a lambda function. The default currently is 60.
• memory_size: This is an integer representing the amount of memory given to the lambda function in MB. The default currently is 128.
• tags: This is a map who's key is the tag name and the value is tag value

These values will be able to vary globally and per stage. These values will be plumbed into both non-SAM and SAM methods of deployment. Here are some examples of how this will look in the config.json:

Globally

{
  "timeout": 120,
  "memory_size": 512,
  "tags": {
     "foo": "bar"
  }
}

This will make sure for all lambda function the values will be:

• timeout: 120 seconds
• memory_size: 512 MB
• tags: foo=bar

Stage

{
  "stages": {
    "dev": {
      "timeout": 120,
      "memory_size": 512,
      "tags": {
        "foo": "bar"
      }
    }
  }
}

This will make sure that for only the dev stage the values will be (all other stages will fallback to the default):

• timeout: 120 seconds
• memory_size: 512 MB
• tags: foo=bar

Then you can override/merge global values through stages. Given:

{
  "timeout": 120,
  "memory_size": 512,
  "tags": {
     "foo": "global-value",
     "biz": "global-value"
  },
  "stages": {
    "dev": {
      "timeout": 240,
      "tags": {
        "foo": "stage-override",
        "bar": "stage-value"
      }
    }
  }
}

The values for the lambda functions in the dev stage would be:

• timeout: 240
• memory_size: 512
• tags: foo=stage-override, biz=global-value, bar=stage-value

Specifics on tags

Tags on a lambda function can be specified on the CreateFunction call, but they cannot be specified in the UpdateFunctionConfiguration call. So for non-SAM deployments, a call will need to be made to ListTags to get all of the tags, add any tags missing from or different in the config.json with TagResource, and remove any tags in the list of tags but not in the config.json with UntagResource.

In terms of the default aws-chalice tag, it will always be included even if the user supplies their own tags. If a user tries to override the tag, it will use the user's provided tag.

Rationale

Q: Why have memory_size and timeout specified on the same level of all the other configurations instead of in a "lambda_config" dictionary?

It would be awkward to isolate the memory_size and timeout to a lambda_config when there is already information like environment_variables that do not live in a lambda_config dictionary in the config.json but are purely related to the lambda configuration.

Q: Why allow users to override aws-chalice tag?

It is because the tag space is typically considered the user's space; they should have the right to override if they want to. It is a bad user experience to prevent users from clobbering the value as customer's could easily just use the API directly to update the tags, which at that point makes the process cumbersome.

[jamesls]

In general I like the feature. Couple of comments:

• I'd prefer not to allow the users to override the aws-chalice tag. We may try to use this for deployments in the future (so you don't need a local deployed.json) so I'd prefer to not make this changeable through chalice. A user can always use the CLI/boto3/console if they want to modify this directly so they still have an option, we're just encouraging them not to change it.

• I think it might be confusing to have timeout and memory_size as top level keys. The thinking with environment variables was that any resources we conceivably could create would get these environment variables injected. That is, it wouldn't have to be conceptually tied to only lambda functions because other resources might support env vars. Same thing with a vpc-id (if/when we support that). However, memory and timeout seem specific to lambda so I'm thinking it makes more sense to make this more clear. If we don't add them to a lambda_config, maybe prefixing them lambda_ would be better?

[kyleknap]

I'm fine with the not allowing the aws-chalice tag not be overriden given it may be used internally for deployments.

In terms of timeout and memory_size, I agree it is lambda specific given there are lambda specific defaults and those would likely not wanted be carried over to other resources.

I like the lambda_ prefix more than the lambda_config given:

• I still find lambda_config confusing given that even though environment_variables, tags, and the IAM stuff could be general, they are really only applied today to the lambda functions and I would not be able to specify them in the lambda_config (unless we added them there as well). I think if more resource types (other than API gateway and Lambda) are added to chalice, then this should be readdressed to look into resource/service specific configuration sections.

• There is already a pattern of service specific configuration with api_gateway_stage with respect to prefixing

[kyleknap]

The implementation has now been merged. Closing out issue.

[frmsaul]

Is the usage of the timeout feature documented somewhere? I couldn't fine it by searching timeout in the docs.

https://chalice.readthedocs.io/en/latest/search.html?q=timeout

I still get timeout after 60 seconds with this is my (more or less) config.json file:

{
  "version": "2.0",
  "app_name": "<my app name>",
  "timeout": 5000,
  "stages": {
    "dev": {
      "api_gateway_stage": "api"
    }
  }
}

Any idea what could be the cause?