Add Terraform var for Tilegarden function name

[KlaasH]

Overview

Adds a tfvar for the name of the Tilegarden Lambda function and uses it to restrict the Lambda execution permission on the TilegardenExecutor role.

See discussion on PR #719

Also

• Uses the tfvar to set the name of the executor role.
• Renames the variable on the Tilegarden side to LAMBDA_FUNCTION_NAME, since that's what it's used for.
• Removes the LAMBDA_ROLE variable from the Tilegarden .env example and uses the LAMBDA_FUNCTION_NAME value with 'Executor' appended to match what Terraform does when creating it.

What this does not do is resolve #714 by incorporating the Lambda-warming scheduled task into Terraform. It turns out giving CloudWatch the permission to invoke a Lambda function is done by defining a policy on the Lambda function and can't be done via IAM role or any sort of resource wildcard.

So trying to define the scheduled warming event before the actual Lambda function exists isn't possible, which means putting it in the Terraform config would add a bunch more complexity to the circular dependency between the Terraform and Claudia deployment steps.

Using a variable to set the function name is useful, though, and since I did that first on the way to configuring the CloudWatch rule and discovering this problem, we might as well keep it.

Notes

Here's a branch with the CloudWatch rule/event config.

Testing Instructions

If run for Staging, starting with current develop deployed:

• With the tilegarden_function_name variable set to the existing function name (pfbTilegardenStaging) infra plan (after the usual setup per the deployment instructions) should show only the usual service task updates (caused by the batch job revision changing) plus a change to the InvokeLambda permission, changing it to a more restrictive resources clause.
• With the variable set to something else, infra plan should show that plus a bunch of changes to the Executor role to remove the one with the old name and create one with the new name.

Checklist

- [ ] Add entry to CHANGELOG.md

[ddohler]

Works as expected. Super annoying that Lambda uses its own special permissions system for this though. Aside from the question I asked, I noticed that GitHub's issue-resolving logic isn't smart enough to understand the negation in What this does not do is resolve #714 so I think #714 will get closed if this is merged without editing the PR text.

[ddohler]

Does this need to get added to the .tfvars files on S3?

[KlaasH]

Yup, will do.

[KlaasH]

I noticed that GitHub's issue-resolving logic isn't smart enough to understand the negation

I wondered whether it would pick that out. I wasn't sure if keywords like that had to be at the beginning of a line. I guess it's probably nice that they don't in some cases, but yeah, false positives...