Lambda layer updating when there were no changes

[samhaaf]

Why does chalice with automatic_layer have to update the lambda layers every time you call deploy? If it knows to use the same deployment package, shouldn't it know it doesn't need to update the layer? This method doesn't really save time like it says in the documentation, because the dependencies are still getting re-deployed.

Example where I run deploy twice:

$ chalice deploy
Creating shared layer deployment package.
Creating app deployment package.
Creating lambda layer: webstack-dev-managed-layer
...
$ chalice deploy
Creating shared layer deployment package.
  Reusing existing shared layer deployment package.
Creating app deployment package.
  Reusing existing app deployment package.
Updating lambda layer: webstack-dev-managed-layer
...

[jamesls]

Yeah, it seems like that's an optimization we should be able to make. The main benefits you get now are 1) skipping the pip download process and 2) sharing the layer across multiple lambda functions, but if you just have a single lambda function it really only saves time by skipping the pip download process.

[res0nat0r]

Also I believe this breaks the shared layers concept outlined in the AWS blog post here.

IE, trying to set a fixed shared layer like so:

{
  "version": "2.0",
  "app_name": "reuse-layer",
  "layers": ["arn:aws:lambda:us-west-2:12345:layer:layerapp-dev-managed-layer:2"],
  "stages": {
    "dev": {
      "api_gateway_stage": "api"
    }
  }
}

Will break upon two subsequent deployments of the same requirements.txt, even though the actual requirements don't change. Since the :version number will get bumped and the previous version deleted, all of the layer sharing will break, even though the actual layer contents haven't been modified, so you can't really point to an 100% known fixed shared layer which you know contains these exact package versions and these versions only, since the version number isn't fixed.

[tfotis]

One more thing that I noticed is that when the deployment is done, using the existing shared layer, it bumps the layer's version in file .chalice/deployed/<stage>.json.

I guess this could also be optimized, since if there isn't a version update, there isn't a need to change that file also. Because If someone is using a versioning system, they would have to commit the file to the repo again after each deployment

[flowtrader2016]

Any update on this as still seeing layer sharing breaking when the :version number is bumped.

[VaZark]

The message Reusing existing shared layer deployment package. implies that chalice can detect if the deployment package has been changed. It just needs to skip updating it.

This is currently breaking the underlying requirement of having stable layers. When using multiple functions sharing a layer, we're forced to build it as a separate package instead of an automatic-layer or have a separate managed layer for each function.

Skipping :version would make config so much easier too

[VaZark]

Some kind of hash can be associated with layer that can be deterministically recreated which can be used to validate against the existing hash of the layer when choosing whether to update.

[mihow]

Would hashing the requirements.txt file be enough? Or is there more that makes the shared layer unique?