Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support AWS Lambda Aliases and Versions #4123

Closed
johannesboyne opened this issue Dec 1, 2015 · 8 comments
Closed

Support AWS Lambda Aliases and Versions #4123

johannesboyne opened this issue Dec 1, 2015 · 8 comments

Comments

@johannesboyne
Copy link
Contributor

I would like to be able to use terraform to configure the aliases and versions for Lambda functions.

I'll try to squeeze in some time to start working on it, but as the terraform acc. test quality is quite high - kudos ;-) - I'll first have to read and understand parts of the testing code.

@johannesboyne
Copy link
Contributor Author

This is the first time I'm contributing to terraform and thus I'm not 100% sure whether everything is done best.
In commit johannesboyne@0fe0625 the lambda function alias support is implemented and I'll continue with function versions later. Just, if somebody would likes to comment on my attempt, please feel free to do so!
When I'm done I would squash aliases and versions into one single commit, if you don't ask me to separate it.

@johannesboyne
Copy link
Contributor Author

I would like to get some feedback on the usage of versions. I cam up with the following:

resource "aws_lambda_function" "lambda_function_test" {
    filename = "test-fixtures/lambdatest.zip"
    function_name = "example_lambda_version_test_name"
    role = "${aws_iam_role.iam_for_lambda.arn}"
    handler = "exports.example"
}

resource "aws_lambda_version" "current_version" {
    function_name = "${aws_lambda_function.lambda_function_test.arn}"
    description = "My description for this version"
}

A version would be pushed with the function creation / update and one could later access it e.g. in an API Gateway configuration. BUT and this but bothers me quite a bit: would anyone actually use it programmatically like this? The only "reasonable" use-case is rolling back to a version because of errors in the Lambda function. But I guess most of the time s3_object_version makes more sense for something like that.

Any opinions on the lambda versioning?

@jen20
Copy link
Contributor

jen20 commented Dec 2, 2015

Hi @johannesboyne! Thanks for opening up an issue, that's definitely the best route to starting to contribute to Terraform. I had a look through your code, and with the exception of the things you commented on yourself, it looks like a pretty good start to me. If you'd like to open it as a pull request and mention this issue number, we can review it properly!

Although the need for setting up aliases for the event source mapping is somewhat reduced by using Terraform to manage them (I think), the recommendation from Amazon is that aliases should be used. Consequently I think this is a good addition to Terraform's coverage of the AWS API.

@johannesboyne
Copy link
Contributor Author

Hi @jen20 great, I'll do it.

My main reason for aliases has been the combination with api gateway.

@grisha
Copy link
Contributor

grisha commented Dec 15, 2015

I'm a Terraform noob, so it's entirely possible that I'm missing something obvious, but as far as I can tell, there is also no mechanism by which the Lambda zip file would be deployed if the zip file has changed, the resourceAwsLambdaFunctionUpdate() looks like it's not yet implemented: https://github.com/hashicorp/terraform/blob/master/builtin/providers/aws/resource_aws_lambda_function.go#L235-L239. It would also be nice if some method existed by which the zip file could be built locally, e.g. if the Lambda contains code that needs to be generated (or a component of the zip file compiled, e.g. a Go program) before apply time.

@mostman1043
Copy link

@johannesboyne - this is really good, we will use this for sure once it becomes integrated. Thanks for taking this on. To answer your question on if/when people would use that, Yes, yes they would :)

Being able to call older versions in places where you are programmatically calling functions (vs trigger or API), is very important to tracking down regressions.

@grisha - Yes, quite unfortunate. I have a workaround for it. Thought about posting it, but I figured it was easier to just say 👍 and ask that it be implemented ;)

@catsby
Copy link
Contributor

catsby commented Jan 13, 2016

Hey all, I merged #4664 (original source from @johannesboyne), so I'm going to close this. Let us know if you need anything else!

@catsby catsby closed this as completed Jan 13, 2016
@ghost
Copy link

ghost commented Apr 28, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Apr 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants