Terraform-provider-aws: Allow creation of Lambda without requiring deployment script location

Created on 20 Sep 2018  ยท  14Comments  ยท  Source: hashicorp/terraform-provider-aws

_This issue was originally opened by @guybumbling as hashicorp/terraform#18905. It was migrated here as a result of the provider split. The original body of the issue is below._


Current Terraform Version

...Terraform v0.11.7

Use-cases


We are attempting to divide the stand-up of new Lambda function infrastructure from actual deployment of the codebase to be executed by the lambda function. AWS allows in console to create a lambda function without need of immediately deploying code to same.
We wish to use Terraform for the creation of the function and Jenkins for the build and deployment of java applications by the developers. Currently we create the Lambda function manually and then a Jenkins project is created to deploy code to the function.

However, we would like to use Terraform to manage the creation of the VPC, Security Groups, Function and variables. Then provide Jenkins projects to Developers who are trained and familiar with deploying in that style.

Problem: Terraform will not allow the creation of a Lambda function without also providing a source (Either 'Local' or 'S3') for the code to be deployed to the new or existing Lambda.

Attempted Solutions


We have been successful in Lambda Stand-up using local source code and S3 - however, this is not the operating model for CI/CD Process with our Developer team. Requiring a re-work of the divide between Developer/Operations team responsibilities.

We have and can add a default code locally for initial deployment. But this just seems unnecessary, as AWS allows for the creation of Lambda Functions without actual initial code deployment.

Proposal


I am proposing a key value that can be set to toggle Terraform to skip the check for source of code to be deployed. Allowing the function to be created in full without any code deployed.
Perhaps I am reading too much into the documentation, but, it does not appear we can create a Lambda without pushing code via TF from Local or S3.
I have created Lambda Functions fully in the Console and via CLI without deployment of code. I am hoping for a solution from the Terraform team to allow us to split what we consider Infrastructure of the Lambda from the Code Deployment to fit our CI/CD Process.

References


I have found other people with the same error, but different reasons and deployment requirements.

enhancement serviclambda

Most helpful comment

Hi @guybumbling ๐Ÿ‘‹ Sorry for any confusion, but looks like there are a few separate pieces that need responses here. Hopefully I can help guide you towards answers to your questions and a solution to help in your environment. If you have questions about any of this please reach out and my apologies if I am misunderstanding anything on my end. ๐Ÿ˜„

Its probably important to note first that this project, the Terraform AWS provider, is an open source project and not managed or associated with Amazon/AWS currently. We (HashiCorp in this case, my employer) partner with AWS for certain things (many under NDA), but this project is generally not associated with AWS timelines, product roadmaps, support structure, or engineering teams. Comments on GitHub issues may be provided by community members, like above, or project maintainers (internal and external to HashiCorp) alike. If you would like further collaboration between AWS and HashiCorp, I suggest reaching out to a technical account manager at either AWS or HashiCorp to discuss that aspect further.


Regarding this GitHub issue being migrated by hashibot (a HashiCorp GitHub bot), that is due to Terraform 0.10 onwards being divided into Terraform core (handles the command line, Terraform state, dependency graph generation, etc.) vs Terraform providers (handle communicating and mapping remote APIs). The Terraform terminology for what defines a "provider" may be different than other software and does not necessarily imply a problem with the associated vendor (AWS). Each of the Terraform providers works with different APIs and has different maintainers.

More information can be found about Terraform providers and the split can be found here:

When a GitHub issue is submitted to Terraform core (https://github.com/hashicorp/terraform) that strictly deals with functionality within a single Terraform provider (e.g. a single AWS provider resource like aws_lambda_function in this case), the maintainers of the Terraform core repository will automatically migrate the issue to the provider so it can be appropriately triaged by the correct maintainers and community. (There is some maintainer overlap between Terraform core and certain Terraform providers, so sometimes you will see issues automatically migrated by someone like myself.)

If you have suggestions for improving the verbiage by hashibot migrating issues between Terraform core and Terraform providers, please let me know and I can relay those to the maintainers of that GitHub bot.

As a related aside for (specifically) the AWS provider GitHub repository: The maintainers will label GitHub issues with the upstream label if the issue or feature request is actually directly or indirectly related to AWS code or behavior.


As for the specific handling of Lambda functions with the Terraform AWS provider, there are a few pieces to consider here. The first being not requiring code with CreateFunction (a feature request), secondly ensuring that we are not needlessly requiring function code for updates (a potential bug), and thirdly leading into the suggestion that using ignore_changes with your Terraform configuration might be a good solution for your environment. Let's step through each of these.

We (Terraform AWS provider maintainers in this case) generally prefer to only implement functionality present in AWS Lambda API and subsequently their AWS Go SDK for the Lambda service. Given that the Lambda API requires some form of source code with CreateFunction currently, we would be hesitant to implement our own solution to workaround that issue unless it does not present a maintenance burden for the project (e.g. extensive updates every time Lambda supports a new runtime or runtime version). If a member of the community (yourself included ๐Ÿ˜„ ) submits an update for this functionality in a way that would not present a maintenance burden for the project, the maintainers here would consider merging it. The same is true if enough community interest is gartered or if the other various means of getting this on the HashiCorp development roadmap are triggered where HashiCorp will consider sponsoring the development.

As for mentions that we may require code updates when updating the Terraform resource, it may appear that way depending on the difference between reality (what is actually in Lambda right now and reflected in your Terraform state) versus the intended configuration (in your Terraform configuration). To fully know or troubleshoot this, we would need to see your terraform plan output, but my best guess without seeing your actual output is that you might be seeing something similar to the below after the initial Terraform deployment of the Lambda function, some outside process updating the Lambda function code, and then running Terraform again to perform a non-code related update:

~ aws_lambda_function.example

  role: "terraform-old-role" => "terraform-new-role"
  s3_key: "jenkins-updated-key" => "terraform-initial-key"

Where role attribute is an example that represents any non-code related change and s3_key attribute is an example that represents any function code related change.

When considering a resource update, many resources including the aws_lambda_function resource, will consider the attributes separately. Here is the update function code of this resource for reference:

https://github.com/terraform-providers/terraform-provider-aws/blob/4d7d210f3643b7434db01fe189ff2424d16ae3f2/aws/resource_aws_lambda_function.go#L625-L861

There are conditionals (e.g. d.HasChange()) for each of the attributes guarding between whether to call Lambda's UpdateFunctionConfiguration, UpdateFunctionCode, PutFunctionConcurrency, and DeleteFunctionConcurrency.

Without any configuration preventing the behavior and given the example terraform plan output above, Terraform will perform both UpdateFunctionConfiguration (performing the non-code update as requested) and UpdateFunctionCode (resetting to the original function code).

Luckily, Terraform has a configuration method to prevent this situation from causing a problem, if desired. Every Terraform resource, regardless of which Terraform provider, accepts a lifecycle configuration block with a few arguments. Inside that configuration block, it accepts an ignore_changes argument, with a list of attributes to ignore updates.

Given our above scenario, we can configure the resource with this additional configuration:

resource "aws_lambda_function" "example" {
  # ... other configuration ...

  role  = "terraform-new-role"
  s3_key = "terraform-initial-key"

  lifecycle {
    ignore_changes = ["s3_key"]
  }
}

Terraform should then show something like the following during terraform plan:

~ aws_lambda_function.example

  role: "terraform-old-role" => "terraform-new-role"

And then if you terraform apply this, only the role attribute update (via UpdateFunctionConfiguration) will occur.


I hope all this makes sense. Again please reach out with any questions!

All 14 comments

To ad one more thing regarding this statement in the original post:
"We have and can add a default code locally for initial deployment. But this just seems unnecessary, as AWS allows for the creation of Lambda Functions without actual initial code deployment."

The above solution leads to the re-deployment of default code whenever we run TF to deploy changes to the variables, kms keys, security groups...etc. Which then requires a re-deployment of the actual code through Jenkins. So, it is a bit of a hack. I hope you can empathize with our desired outcome and provide a solution for Blank Lambda functions to be created from Terraform.

As for the comment in the email regarding this ticket migration to the Provider queue: "it looks like an issue with that provider. If you believe this is not an issue with the provider, please reply to"
My response Perhaps I am mistaken, But, I belive this is NOT a provider issue (if by provider you mean AWS) This is a Terraform issue as AWS seems allow for the creation of a Lambda Function complete with variables without need to push teh actual function code.

@guybumbling Ref: https://github.com/aws/aws-sdk-go/issues/2183
this is why when we creating the lambda function in web console without source code, it works.
I don't think it's better idea to replicate the same here, since we need to do it for all languages and it will have new version and updates.

Regarding your requirement, you can provide some template code(few lines like AWS console) as source code when creating the lambda function using terraform and then use Jenkins to update the code.

Yes, that is what we are doing...But, This is a huge problem with outages
in a Production environment and requirements to plan such downtime as we
deploy infrastructure and then re-deploy lambda code. Your response was not
what i was hoping for in any way, shape or form.

Infrastructure as code, should be 100% separate from Application
deployment. If I had to re-deploy applications every time I needed to make
a change to an ELB or SG in a standard ECS Stack...that would be wholly
unworkable. Same is true here with creating code for Lambda infrastructure.
I hope this makes the issue a bit clearer. Production Assets are
significantly affected when a desire to push a simple change to a Lambda
function (such as policy, timeout, tagging, variables...etc) which our
operations team is require to perform. And with Lambda fan where new
functions are being added on a regular basis...your solution and approach
is unworkable.

How can we get this topic escalated for further discussion and possible
road-mapping?

Thank you,
David Gotlieb
System Engineer
CMS Ops & Engineering
480-220-3126

On Thu, Oct 4, 2018 at 2:32 PM Saravanan Palanisamy <
[email protected]> wrote:

@guybumbling
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_guybumbling&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=qfz24INtMnSNxeVSmwvpkefLnm6dtTyKkteXRdJZXcc&s=mMOX8AfLGBfSeZFWmC-MzORL_nDUiRYOO43zlLuV7fc&e=
Ref: aws/aws-sdk-go#2183
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_aws_aws-2Dsdk-2Dgo_issues_2183&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=qfz24INtMnSNxeVSmwvpkefLnm6dtTyKkteXRdJZXcc&s=qLjZMuJSVcFhK7DOE6579xkyQk4NaTtq89BjaLhiorY&e=
this is why when we creating the lambda function in web console without
source code, it works.
I don't think it's better idea to replicate the same here, since we need
to do it for all languages and it will have new version and updates.

Regarding your requirement, you can provide some template code(few lines
like AWS console) as source code when creating the lambda function using
terraform and then use Jenkins to update the code.

โ€”
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_terraform-2Dproviders_terraform-2Dprovider-2Daws_issues_5945-23issuecomment-2D427176796&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=qfz24INtMnSNxeVSmwvpkefLnm6dtTyKkteXRdJZXcc&s=_TW4JBTV4DUe13GoBMgzy42GeslyGNTTsTCtEm2akqY&e=,
or mute the thread
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AX1aTwXAyng6qKBTR96qRsv5i5ByQzmMks5uhn56gaJpZM4WyXEi&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=qfz24INtMnSNxeVSmwvpkefLnm6dtTyKkteXRdJZXcc&s=Uz7WmUDF3tv_Vq8mVGIprwI7QCttPBtcA1A9ApIxDJg&e=
.

Saravanan,

We have a corporate service contract. Should I escalate this thread through
our service request ticketing system with AWS and reference this thread?

Thank you,
David Gotlieb
System Engineer
CMS Ops & Engineering
480-220-3126

On Thu, Oct 4, 2018 at 2:51 PM Gotlieb, Dave dave.gotlieb@pearson.com
wrote:

Yes, that is what we are doing...But, This is a huge problem with outages
in a Production environment and requirements to plan such downtime as we
deploy infrastructure and then re-deploy lambda code. Your response was not
what i was hoping for in any way, shape or form.

Infrastructure as code, should be 100% separate from Application
deployment. If I had to re-deploy applications every time I needed to make
a change to an ELB or SG in a standard ECS Stack...that would be wholly
unworkable. Same is true here with creating code for Lambda infrastructure.
I hope this makes the issue a bit clearer. Production Assets are
significantly affected when a desire to push a simple change to a Lambda
function (such as policy, timeout, tagging, variables...etc) which our
operations team is require to perform. And with Lambda fan where new
functions are being added on a regular basis...your solution and approach
is unworkable.

How can we get this topic escalated for further discussion and possible
road-mapping?

Thank you,
David Gotlieb
System Engineer
CMS Ops & Engineering
480-220-3126

On Thu, Oct 4, 2018 at 2:32 PM Saravanan Palanisamy <
[email protected]> wrote:

@guybumbling
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_guybumbling&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=qfz24INtMnSNxeVSmwvpkefLnm6dtTyKkteXRdJZXcc&s=mMOX8AfLGBfSeZFWmC-MzORL_nDUiRYOO43zlLuV7fc&e=
Ref: aws/aws-sdk-go#2183
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_aws_aws-2Dsdk-2Dgo_issues_2183&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=qfz24INtMnSNxeVSmwvpkefLnm6dtTyKkteXRdJZXcc&s=qLjZMuJSVcFhK7DOE6579xkyQk4NaTtq89BjaLhiorY&e=
this is why when we creating the lambda function in web console without
source code, it works.
I don't think it's better idea to replicate the same here, since we need
to do it for all languages and it will have new version and updates.

Regarding your requirement, you can provide some template code(few lines
like AWS console) as source code when creating the lambda function using
terraform and then use Jenkins to update the code.

โ€”
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_terraform-2Dproviders_terraform-2Dprovider-2Daws_issues_5945-23issuecomment-2D427176796&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=qfz24INtMnSNxeVSmwvpkefLnm6dtTyKkteXRdJZXcc&s=_TW4JBTV4DUe13GoBMgzy42GeslyGNTTsTCtEm2akqY&e=,
or mute the thread
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AX1aTwXAyng6qKBTR96qRsv5i5ByQzmMks5uhn56gaJpZM4WyXEi&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=qfz24INtMnSNxeVSmwvpkefLnm6dtTyKkteXRdJZXcc&s=Uz7WmUDF3tv_Vq8mVGIprwI7QCttPBtcA1A9ApIxDJg&e=
.

@bflad share your thoughts.

Hi, I have placed a Feature Request through the AWS Ticketing system. Ref: Case ID 5413405241. I have referenced this thread in the request and am hoping we can get two ends working together toward the middle on this one. From what I am reading out there, this would be very helpful to more than just our team. Thank you again for your time and attention to this request.

  • Dave

Hi, I am adding the history of the case open directly with AWS Support andr esponses in reverse chronological order as dated below. Please see the reply from Nick M. regarding no requirement for teh API to deploy code on updates to existing lambda functions - only for create function api calls. It appears to me that Terraform must be initially creating the Lambda, and correctly using the create lambda api call which does require code deployment (as we all knew). However, updates to existing lambda functions via api calls do not require that the code be re-deployed.
After reviewing AWS team's response and explanation, it seems to me, that Terraform code may be forcing the 'create' api call every time an update is made to the function(s), rather than first checking to see if the function exists and then ignoring the 'create' call and simply executing the changes to other aspects (Roles, variables...etc). The function names are in the state files, so, Terraform can be made to ignore ongoing create calls for existing functions. It seems to me, that if this is accomplished, the issue of ongoing code deployment with successive 'terraform apply' can be solved. In that case, this is no longer a Terraform API Team support issue and should be sent back to the terraform team to find a fix and work-around to NOT place subsequent 'creat' calls on updates to existing functions.

* My request: That the Terraform Provider Team and the Terraform Developer Teams review this issue together (referring back to my original request with Terraform who moved the request here) and see if a solution can be readily created to adjust how Terraform is placing api calls when updating existing Lambda functions that were originally created by terraform and show existing in the tf state files..
The alternate solution will be to place the feature request within AWS, which, I expect, would be a much longer path to resolution.

Thanks, Dave G.

Reply and next steps regarding this open AWS Case sent Oct 8, 2018
Hi Nick M, Thank you for your reply and related information and background. The issue we are experiencing appears to be a catch-22 with how Terraform is deploying and maintaining it's state files with regard to initial creation and then any subsequent api call on performing updates to a Lambda function. It is very possible that the api call to create function is used within Terraform again when other aspects of the function are updated, causing a requirement from the API for the zip file to deploy. I am going to provide this information in the open request with Terraform Providers as well as in my original ticket with Terraform itself. One of two things would need to be addressed to fix our user experience. Either: 1) AWS to execute a feature request to allow the create lambda call to execute without code, Or, 2) Terraform will need to modify their approach to allow for initial creation of a lambda and then NOT make ongoing create lambda calls on subsequent updates of an existing function. Let's see how the Terraform team responds to this new information. I am keeping this case open for now for tracking.

Thanks, Dave G

AWS Response received Oct 6, 2018
Thank you for the specific details of your request. I am not an expert with Terraform, but I would like to speak to your request in context of the specific API calls that are made to the AWS Lambda service. These APIs, and their documentation are: - CreateFunction: https://docs.aws.amazon.com/lambda/latest/dg/API_CreateFunction.html - UpdateFunctionCode: https://docs.aws.amazon.com/lambda/latest/dg/API_UpdateFunctionCode.html - UpdateFunctionConfiguration: https://docs.aws.amazon.com/lambda/latest/dg/API_UpdateFunctionConfiguration.html - TagResource: https://docs.aws.amazon.com/lambda/latest/dg/API_TagResource.html - AddPermission: https://docs.aws.amazon.com/lambda/latest/dg/API_AddPermission.html Updating the timeout and environment variables can be done with the UpdateFunctionConfiguration API call, without modifying the function code. Modifying tags or resource policies are also separate calls, and do not require a change to the function code. Code changes should be done with an API call to UpdateFunctionCode. You will need to reference Terraform documentation to determine if you are able to call the appropriate APIs calls from the tool. You are correct that the initial CreateFunction API call does require a FunctionCode object [1] to be passed in the JSON. You are not required to include runtime specific code with this case, the only requirement is that you supply a non-empty zip file. At your request, I can open a feature request with our Lambda team for the FunctionCode object requirement to be 'optional' for CreateFunction calls, but first I want your team to be aware that function updates can be performed without a code change. Please also review our documentation on automating deployments of your serverless applications [2], which can be accomplished with AWS CodeDeploy.

- Nick M.

Initial AWS Case opened Oct 4, 2018
Hi, We are increasingly utilizing Lambda for executing processes that are called by other functions and other services both external and internal to our account. We have found that the requirement to load actual code to the function at time of standup, or subsequently when we are making updates to infrastructure (such as environment variables, timeout limits, tagging...etc) is becoming problematic. Infrastructure as code, should be 100% separate from Application deployment. In this way, an operations team can make changes to infrastructure on the fly without disruption to existing application code. As it is, we deploy code via Jenkins CI/CD where the developers manage their own pipelines and deployment windows. With ECS/Docker, this is very simple and changes to infrastructure are 100% separate from code deployment. Problem with Lambda and coding our infrastructure: AWS will not allow the creation or management of a Lambda functions (with the exception of manual changes in console) without also providing a source (Either 'Local' or 'S3') for the code to be deployed to the new or existing Lambda. It has been suggested that we do what we have been doing, which is to have a simple blank base code that deploys with updates to Lambda via Terraform. Then (with the function now out of service) Re-run a Jenkins build to re-deploy the code. Expand that to 5, 10, 20 functions' Infrastructure managed for a project via code, and you can see how this is unworkable in lower environments and wholly unworkable in a Production environment. I had raised the following incident initially with Terraform directly. They moved the request to here: [terraform-providers/terraform-provider-aws] Allow creation of Lambda without requiring deployment script location (#5945) https://github.com/terraform-providers/terraform-provider-aws/issues/5945 The AWS Rep responding to my query above referenced yet another ticket with a similar quandary for my review and then stated, "this is why when we creating the lambda function in web console without source code, it works. I don't think it's better idea to replicate the same here, since we need to do it for all languages and it will have new version and updates. Regarding your requirement, you can provide some template code(few lines like AWS console) as source code when creating the lambda function using Terraform and then use Jenkins to update the code." Well, we know the 'Why', the question is, can there be a change to this to allow for 'Option' code deployment vs 'Required' code deployment with the lambda infrastructure. We believe that this requirement for code deployment with infrastructure is, perhaps, well meant. However, it does not meet with the standard model of infrastructure management as code. In fact is muddies the water where application code and infrastructure code are too integrally entwined. As such, I hope to open a further review into how this may be fixed to allow and 'Optional' code deployment, rather than a 'Required' code deployment. Thank you for your time and attention to this request. It would hugely benefit many operational teams, such as ours. p.s. Please escalate this request to our Pearson AWS Service rep who handles architecture requests such as these.
Thanks, Dave G

Hi @guybumbling ๐Ÿ‘‹ Sorry for any confusion, but looks like there are a few separate pieces that need responses here. Hopefully I can help guide you towards answers to your questions and a solution to help in your environment. If you have questions about any of this please reach out and my apologies if I am misunderstanding anything on my end. ๐Ÿ˜„

Its probably important to note first that this project, the Terraform AWS provider, is an open source project and not managed or associated with Amazon/AWS currently. We (HashiCorp in this case, my employer) partner with AWS for certain things (many under NDA), but this project is generally not associated with AWS timelines, product roadmaps, support structure, or engineering teams. Comments on GitHub issues may be provided by community members, like above, or project maintainers (internal and external to HashiCorp) alike. If you would like further collaboration between AWS and HashiCorp, I suggest reaching out to a technical account manager at either AWS or HashiCorp to discuss that aspect further.


Regarding this GitHub issue being migrated by hashibot (a HashiCorp GitHub bot), that is due to Terraform 0.10 onwards being divided into Terraform core (handles the command line, Terraform state, dependency graph generation, etc.) vs Terraform providers (handle communicating and mapping remote APIs). The Terraform terminology for what defines a "provider" may be different than other software and does not necessarily imply a problem with the associated vendor (AWS). Each of the Terraform providers works with different APIs and has different maintainers.

More information can be found about Terraform providers and the split can be found here:

When a GitHub issue is submitted to Terraform core (https://github.com/hashicorp/terraform) that strictly deals with functionality within a single Terraform provider (e.g. a single AWS provider resource like aws_lambda_function in this case), the maintainers of the Terraform core repository will automatically migrate the issue to the provider so it can be appropriately triaged by the correct maintainers and community. (There is some maintainer overlap between Terraform core and certain Terraform providers, so sometimes you will see issues automatically migrated by someone like myself.)

If you have suggestions for improving the verbiage by hashibot migrating issues between Terraform core and Terraform providers, please let me know and I can relay those to the maintainers of that GitHub bot.

As a related aside for (specifically) the AWS provider GitHub repository: The maintainers will label GitHub issues with the upstream label if the issue or feature request is actually directly or indirectly related to AWS code or behavior.


As for the specific handling of Lambda functions with the Terraform AWS provider, there are a few pieces to consider here. The first being not requiring code with CreateFunction (a feature request), secondly ensuring that we are not needlessly requiring function code for updates (a potential bug), and thirdly leading into the suggestion that using ignore_changes with your Terraform configuration might be a good solution for your environment. Let's step through each of these.

We (Terraform AWS provider maintainers in this case) generally prefer to only implement functionality present in AWS Lambda API and subsequently their AWS Go SDK for the Lambda service. Given that the Lambda API requires some form of source code with CreateFunction currently, we would be hesitant to implement our own solution to workaround that issue unless it does not present a maintenance burden for the project (e.g. extensive updates every time Lambda supports a new runtime or runtime version). If a member of the community (yourself included ๐Ÿ˜„ ) submits an update for this functionality in a way that would not present a maintenance burden for the project, the maintainers here would consider merging it. The same is true if enough community interest is gartered or if the other various means of getting this on the HashiCorp development roadmap are triggered where HashiCorp will consider sponsoring the development.

As for mentions that we may require code updates when updating the Terraform resource, it may appear that way depending on the difference between reality (what is actually in Lambda right now and reflected in your Terraform state) versus the intended configuration (in your Terraform configuration). To fully know or troubleshoot this, we would need to see your terraform plan output, but my best guess without seeing your actual output is that you might be seeing something similar to the below after the initial Terraform deployment of the Lambda function, some outside process updating the Lambda function code, and then running Terraform again to perform a non-code related update:

~ aws_lambda_function.example

  role: "terraform-old-role" => "terraform-new-role"
  s3_key: "jenkins-updated-key" => "terraform-initial-key"

Where role attribute is an example that represents any non-code related change and s3_key attribute is an example that represents any function code related change.

When considering a resource update, many resources including the aws_lambda_function resource, will consider the attributes separately. Here is the update function code of this resource for reference:

https://github.com/terraform-providers/terraform-provider-aws/blob/4d7d210f3643b7434db01fe189ff2424d16ae3f2/aws/resource_aws_lambda_function.go#L625-L861

There are conditionals (e.g. d.HasChange()) for each of the attributes guarding between whether to call Lambda's UpdateFunctionConfiguration, UpdateFunctionCode, PutFunctionConcurrency, and DeleteFunctionConcurrency.

Without any configuration preventing the behavior and given the example terraform plan output above, Terraform will perform both UpdateFunctionConfiguration (performing the non-code update as requested) and UpdateFunctionCode (resetting to the original function code).

Luckily, Terraform has a configuration method to prevent this situation from causing a problem, if desired. Every Terraform resource, regardless of which Terraform provider, accepts a lifecycle configuration block with a few arguments. Inside that configuration block, it accepts an ignore_changes argument, with a list of attributes to ignore updates.

Given our above scenario, we can configure the resource with this additional configuration:

resource "aws_lambda_function" "example" {
  # ... other configuration ...

  role  = "terraform-new-role"
  s3_key = "terraform-initial-key"

  lifecycle {
    ignore_changes = ["s3_key"]
  }
}

Terraform should then show something like the following during terraform plan:

~ aws_lambda_function.example

  role: "terraform-old-role" => "terraform-new-role"

And then if you terraform apply this, only the role attribute update (via UpdateFunctionConfiguration) will occur.


I hope all this makes sense. Again please reach out with any questions!

Brian,
Thank you for your very detailed explanation of the terraform development
tracks and Core vs Provider tracks. Very informative and provides me (and I
hope others that read this post) much cleaner insight into the dividing
lines of what is Hashicorp owned and what is open source developed.

Also, thank you for the thoughtful approach to our specific problem and
managing Lambda infrastructure with Terraform within the constraints of our
current CI/CD Process. What you have laid out makes sense, and I will be
attempting this solution approach to the problem shortly. I will post back
here when the results are in.

Thank you,
David Gotlieb
System Engineer
CMS Ops & Engineering
480-220-3126

On Mon, Oct 8, 2018 at 6:00 PM Brian Flad notifications@github.com wrote:

Hi @guybumbling
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_guybumbling&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=4T8pSEqB0Y4sxQce7GOoyx4ZuziWKZMY7qwlkm8HzHE&e=
๐Ÿ‘‹ Sorry for any confusion, but looks like there are a few separate
pieces that need responses here. Hopefully I can help guide you towards
answers to your questions and a solution to help in your environment. If
you have questions about any of this please reach out and my apologies if I
am misunderstanding anything on my end. ๐Ÿ˜„

Its probably important to note first that this project, the Terraform AWS
provider, is an open source project and not managed or associated with
Amazon/AWS currently. We (HashiCorp in this case, my employer) partner with
AWS for certain things (many under NDA), but this project is generally not
associated with AWS timelines, product roadmaps, support structure, or
engineering teams. Comments on GitHub issues may be provided by community
members, like above, or project maintainers (internal and external to
HashiCorp) alike. If you would like further collaboration between AWS and
HashiCorp, I suggest reaching out to a technical account manager at either

AWS or HashiCorp to discuss that aspect further.

Regarding this GitHub issue being migrated by hashibot (a HashiCorp
GitHub bot), that is due to Terraform 0.10 onwards being divided into
Terraform core (handles the command line, Terraform state, dependency graph
generation, etc.) vs Terraform providers (handle communicating and mapping
remote APIs). The Terraform terminology for what defines a "provider" may
be different than other software and does not necessarily imply a problem
with the associated vendor (AWS). Each of the Terraform providers works
with different APIs and has different maintainers.

More information can be found about Terraform providers and the split can
be found here:

-
https://www.hashicorp.com/blog/upcoming-provider-changes-in-terraform-0-10
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.hashicorp.com_blog_upcoming-2Dprovider-2Dchanges-2Din-2Dterraform-2D0-2D10&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=A0r5zW60GA_hNOGDMxcWLjWlh-bnSfolW4cUfU6HH_E&e=

When a GitHub issue is submitted to Terraform core (
https://github.com/hashicorp/terraform
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_hashicorp_terraform&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=Len5ymRL8lk66wzr0LlpTtHvvDzLtw5qdofroeU9Z1k&e=)
that strictly deals with functionality within a single Terraform provider
(e.g. a single AWS provider resource like aws_lambda_function in this
case), the maintainers of the Terraform core repository will automatically
migrate the issue to the provider so it can be appropriately triaged by the
correct maintainers and community. (There is some maintainer overlap
between Terraform core and certain Terraform providers, so sometimes you
will see issues automatically migrated by someone like myself.)

If you have suggestions for improving the verbiage by hashibot migrating
issues between Terraform core and Terraform providers, please let me know
and I can relay those to the maintainers of that GitHub bot.

As a related aside for (specifically) the AWS provider GitHub repository:
The maintainers will label GitHub issues with the upstream label if the
issue or feature request is actually directly or indirectly related to AWS

code or behavior.

As for the specific handling of Lambda functions with the Terraform AWS
provider, there are a few pieces to consider here. The first being not
requiring code with CreateFunction (a feature request), secondly ensuring
that we are not needlessly requiring function code for updates (a potential
bug), and thirdly leading into the suggestion that using ignore_changes
with your Terraform configuration might be a good solution for your
environment. Let's step through each of these.

We (Terraform AWS provider maintainers in this case) generally prefer to
only implement functionality present in AWS Lambda API
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.aws.amazon.com_lambda_latest_dg_API-5FReference.html&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=MJLtGOAWxkc7jHo2PbSuNt_6B8S7mmfjR0OSF7R15tU&e=
and subsequently their AWS Go SDK for the Lambda service
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.aws.amazon.com_sdk-2Dfor-2Dgo_api_service_lambda_&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=nEK4kxnvxcr2DRKW8qMsXDHAxpOmolXZN3oZc5UXK20&e=.
Given that the Lambda API requires some form of source code with
CreateFunction currently, we would be hesitant to implement our own
solution to workaround that issue unless it does not present a maintenance
burden for the project (e.g. extensive updates every time Lambda supports a
new runtime or runtime version). If a member of the community (yourself
included ๐Ÿ˜„ ) submits an update for this functionality in a way that
would not present a maintenance burden for the project, the maintainers
here would consider merging it. The same is true if enough community
interest is gartered or if the other various means of getting this on the
HashiCorp development roadmap are triggered where HashiCorp will consider
sponsoring the development.

As for mentions that we may require code updates when updating the
Terraform resource, it may appear that way depending on the difference
between reality (what is actually in Lambda right now and reflected in your
Terraform state) versus the intended configuration (in your Terraform
configuration). To fully know or troubleshoot this, we would need to see
your terraform plan output, but my best guess without seeing your actual
output is that you might be seeing something similar to the below after the
initial Terraform deployment of the Lambda function, some outside process
updating the Lambda function code, and then running Terraform again to
perform a non-code related update:

~ aws_lambda_function.example

role: "terraform-old-role" => "terraform-new-role"
s3_key: "jenkins-updated-key" => "terraform-initial-key"

Where role attribute is an example that represents any non-code related
change and s3_key attribute is an example that represents any function
code related change.

When considering a resource update, many resources including the
aws_lambda_function resource, will consider the attributes separately.
Here is the update function code of this resource for reference:

https://github.com/terraform-providers/terraform-provider-aws/blob/4d7d210f3643b7434db01fe189ff2424d16ae3f2/aws/resource_aws_lambda_function.go#L625-L861
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_terraform-2Dproviders_terraform-2Dprovider-2Daws_blob_4d7d210f3643b7434db01fe189ff2424d16ae3f2_aws_resource-5Faws-5Flambda-5Ffunction.go-23L625-2DL861&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=is2sBHgQGQtlw9QMF81rWMSZHl_svtzoDjeFtWwuSVY&e=

There are conditionals (e.g. d.HasChange()) for each of the attributes
guarding between whether to call Lambda's UpdateFunctionConfiguration,
UpdateFunctionCode, PutFunctionConcurrency, and DeleteFunctionConcurrency.

Without any configuration preventing the behavior and given the example terraform
plan output above, Terraform will perform both UpdateFunctionConfiguration
(performing the non-code update as requested) and UpdateFunctionCode
(resetting to the original function code).

Luckily, Terraform has a configuration method to prevent this situation
from causing a problem, if desired. Every Terraform resource, regardless of
which Terraform provider, accepts a lifecycle configuration block
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.terraform.io_docs_configuration_resources.html-23lifecycle&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=VaX8D4ew_EuqzQ_si0oDYDX6TWGA7rxgU867KrYDzTg&e=
with a few arguments. Inside that configuration block, it accepts an
ignore_changes argument
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.terraform.io_docs_configuration_resources.html-23ignore-5Fchanges&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=cS-ucjgN5tvmJtMcVheo_T6ga9W8EwLrVdajKT4DTAc&e=,
with a list of attributes to ignore updates.

Given our above scenario, we can configure the resource with this
additional configuration:

resource "aws_lambda_function" "example" {
# ... other configuration ...

role = "terraform-new-role"
s3_key = "terraform-initial-key"

lifecycle {
ignore_changes = ["s3_key"]
}
}

Terraform should then show something like the following during terraform
plan:

~ aws_lambda_function.example

role: "terraform-old-role" => "terraform-new-role"

And then if you terraform apply this, only the role attribute update (via

UpdateFunctionConfiguration) will occur.

I hope all this makes sense. Again please reach out with any questions!

โ€”
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_terraform-2Dproviders_terraform-2Dprovider-2Daws_issues_5945-23issuecomment-2D428025312&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=nXbH3oFIdQzeg9FIMFkGzhUY8lZeweXEgA84y61eAZg&e=,
or mute the thread
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AX1aT4u-5FiE-2DpRefr4YF7aS3mFMIZbda0ks5ui-5FU-5FgaJpZM4WyXEi&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=gUaNZrcik7eF_Z8QyGSdiNDjrTEKl1vbR5ZfhxMw5hI&e=
.

Brian,
Your suggested addition of 'lifecycle with ignore_changes' was exactly what
the doctor ordered for our use-case need. Thank you very much. I hope this
thread is found by others who have been struggling with the same quandary.
Such a simple existing solution to the problem, very much preferred. ;)

Thank you,
David Gotlieb
System Engineer
CMS Ops & Engineering
480-220-3126

On Tue, Oct 9, 2018 at 6:15 AM Gotlieb, Dave dave.gotlieb@pearson.com
wrote:

Brian,
Thank you for your very detailed explanation of the terraform development
tracks and Core vs Provider tracks. Very informative and provides me (and I
hope others that read this post) much cleaner insight into the dividing
lines of what is Hashicorp owned and what is open source developed.

Also, thank you for the thoughtful approach to our specific problem and
managing Lambda infrastructure with Terraform within the constraints of our
current CI/CD Process. What you have laid out makes sense, and I will be
attempting this solution approach to the problem shortly. I will post back
here when the results are in.

Thank you,
David Gotlieb
System Engineer
CMS Ops & Engineering
480-220-3126

On Mon, Oct 8, 2018 at 6:00 PM Brian Flad notifications@github.com
wrote:

Hi @guybumbling
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_guybumbling&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=4T8pSEqB0Y4sxQce7GOoyx4ZuziWKZMY7qwlkm8HzHE&e=
๐Ÿ‘‹ Sorry for any confusion, but looks like there are a few separate
pieces that need responses here. Hopefully I can help guide you towards
answers to your questions and a solution to help in your environment. If
you have questions about any of this please reach out and my apologies if I
am misunderstanding anything on my end. ๐Ÿ˜„

Its probably important to note first that this project, the Terraform AWS
provider, is an open source project and not managed or associated with
Amazon/AWS currently. We (HashiCorp in this case, my employer) partner with
AWS for certain things (many under NDA), but this project is generally not
associated with AWS timelines, product roadmaps, support structure, or
engineering teams. Comments on GitHub issues may be provided by community
members, like above, or project maintainers (internal and external to
HashiCorp) alike. If you would like further collaboration between AWS and
HashiCorp, I suggest reaching out to a technical account manager at either

AWS or HashiCorp to discuss that aspect further.

Regarding this GitHub issue being migrated by hashibot (a HashiCorp
GitHub bot), that is due to Terraform 0.10 onwards being divided into
Terraform core (handles the command line, Terraform state, dependency graph
generation, etc.) vs Terraform providers (handle communicating and mapping
remote APIs). The Terraform terminology for what defines a "provider" may
be different than other software and does not necessarily imply a problem
with the associated vendor (AWS). Each of the Terraform providers works
with different APIs and has different maintainers.

More information can be found about Terraform providers and the split can
be found here:

-
https://www.hashicorp.com/blog/upcoming-provider-changes-in-terraform-0-10
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.hashicorp.com_blog_upcoming-2Dprovider-2Dchanges-2Din-2Dterraform-2D0-2D10&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=A0r5zW60GA_hNOGDMxcWLjWlh-bnSfolW4cUfU6HH_E&e=

When a GitHub issue is submitted to Terraform core (
https://github.com/hashicorp/terraform
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_hashicorp_terraform&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=Len5ymRL8lk66wzr0LlpTtHvvDzLtw5qdofroeU9Z1k&e=)
that strictly deals with functionality within a single Terraform provider
(e.g. a single AWS provider resource like aws_lambda_function in this
case), the maintainers of the Terraform core repository will automatically
migrate the issue to the provider so it can be appropriately triaged by the
correct maintainers and community. (There is some maintainer overlap
between Terraform core and certain Terraform providers, so sometimes you
will see issues automatically migrated by someone like myself.)

If you have suggestions for improving the verbiage by hashibot migrating
issues between Terraform core and Terraform providers, please let me know
and I can relay those to the maintainers of that GitHub bot.

As a related aside for (specifically) the AWS provider GitHub repository:
The maintainers will label GitHub issues with the upstream label if the
issue or feature request is actually directly or indirectly related to AWS

code or behavior.

As for the specific handling of Lambda functions with the Terraform AWS
provider, there are a few pieces to consider here. The first being not
requiring code with CreateFunction (a feature request), secondly
ensuring that we are not needlessly requiring function code for updates (a
potential bug), and thirdly leading into the suggestion that using
ignore_changes with your Terraform configuration might be a good
solution for your environment. Let's step through each of these.

We (Terraform AWS provider maintainers in this case) generally prefer to
only implement functionality present in AWS Lambda API
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.aws.amazon.com_lambda_latest_dg_API-5FReference.html&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=MJLtGOAWxkc7jHo2PbSuNt_6B8S7mmfjR0OSF7R15tU&e=
and subsequently their AWS Go SDK for the Lambda service
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.aws.amazon.com_sdk-2Dfor-2Dgo_api_service_lambda_&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=nEK4kxnvxcr2DRKW8qMsXDHAxpOmolXZN3oZc5UXK20&e=.
Given that the Lambda API requires some form of source code with
CreateFunction currently, we would be hesitant to implement our own
solution to workaround that issue unless it does not present a maintenance
burden for the project (e.g. extensive updates every time Lambda supports a
new runtime or runtime version). If a member of the community (yourself
included ๐Ÿ˜„ ) submits an update for this functionality in a way that
would not present a maintenance burden for the project, the maintainers
here would consider merging it. The same is true if enough community
interest is gartered or if the other various means of getting this on the
HashiCorp development roadmap are triggered where HashiCorp will consider
sponsoring the development.

As for mentions that we may require code updates when updating the
Terraform resource, it may appear that way depending on the difference
between reality (what is actually in Lambda right now and reflected in your
Terraform state) versus the intended configuration (in your Terraform
configuration). To fully know or troubleshoot this, we would need to see
your terraform plan output, but my best guess without seeing your actual
output is that you might be seeing something similar to the below after the
initial Terraform deployment of the Lambda function, some outside process
updating the Lambda function code, and then running Terraform again to
perform a non-code related update:

~ aws_lambda_function.example

role: "terraform-old-role" => "terraform-new-role"
s3_key: "jenkins-updated-key" => "terraform-initial-key"

Where role attribute is an example that represents any non-code related
change and s3_key attribute is an example that represents any function
code related change.

When considering a resource update, many resources including the
aws_lambda_function resource, will consider the attributes separately.
Here is the update function code of this resource for reference:

https://github.com/terraform-providers/terraform-provider-aws/blob/4d7d210f3643b7434db01fe189ff2424d16ae3f2/aws/resource_aws_lambda_function.go#L625-L861
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_terraform-2Dproviders_terraform-2Dprovider-2Daws_blob_4d7d210f3643b7434db01fe189ff2424d16ae3f2_aws_resource-5Faws-5Flambda-5Ffunction.go-23L625-2DL861&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=is2sBHgQGQtlw9QMF81rWMSZHl_svtzoDjeFtWwuSVY&e=

There are conditionals (e.g. d.HasChange()) for each of the attributes
guarding between whether to call Lambda's UpdateFunctionConfiguration,
UpdateFunctionCode, PutFunctionConcurrency, and DeleteFunctionConcurrency
.

Without any configuration preventing the behavior and given the example terraform
plan output above, Terraform will perform both
UpdateFunctionConfiguration (performing the non-code update as
requested) and UpdateFunctionCode (resetting to the original function
code).

Luckily, Terraform has a configuration method to prevent this situation
from causing a problem, if desired. Every Terraform resource, regardless of
which Terraform provider, accepts a lifecycle configuration block
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.terraform.io_docs_configuration_resources.html-23lifecycle&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=VaX8D4ew_EuqzQ_si0oDYDX6TWGA7rxgU867KrYDzTg&e=
with a few arguments. Inside that configuration block, it accepts an
ignore_changes argument
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.terraform.io_docs_configuration_resources.html-23ignore-5Fchanges&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=cS-ucjgN5tvmJtMcVheo_T6ga9W8EwLrVdajKT4DTAc&e=,
with a list of attributes to ignore updates.

Given our above scenario, we can configure the resource with this
additional configuration:

resource "aws_lambda_function" "example" {
# ... other configuration ...

role = "terraform-new-role"
s3_key = "terraform-initial-key"

lifecycle {
ignore_changes = ["s3_key"]
}
}

Terraform should then show something like the following during terraform
plan:

~ aws_lambda_function.example

role: "terraform-old-role" => "terraform-new-role"

And then if you terraform apply this, only the role attribute update

(via UpdateFunctionConfiguration) will occur.

I hope all this makes sense. Again please reach out with any questions!

โ€”
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_terraform-2Dproviders_terraform-2Dprovider-2Daws_issues_5945-23issuecomment-2D428025312&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=nXbH3oFIdQzeg9FIMFkGzhUY8lZeweXEgA84y61eAZg&e=,
or mute the thread
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AX1aT4u-5FiE-2DpRefr4YF7aS3mFMIZbda0ks5ui-5FU-5FgaJpZM4WyXEi&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=dCI8VRBv5ZBwZCQ7CSYk4h0cGeK_qf0lZIihxvjyByk&s=gUaNZrcik7eF_Z8QyGSdiNDjrTEKl1vbR5ZfhxMw5hI&e=
.

The proposed solution still requires me to upload an item to a bucket before running terraform against a new region. This means I have to keep my lambdas in a different terraform run from the rest of my infrastructure since the bucket needs to exist and have objects uploaded to it before I can re-initialize my lambdas. I would prefer to only have to run terraform one time and then let my CI/CD pipelines update the lambdas with the correct code.

This especially is unuseful during a disaster recovery event where the primary region is unavailable. We need to launch the whole infrastructure before those objects are rebuilt.

Amazon allows the creation of empty lambdas, so I would like terraform lambda to mirror this functionality.

@fishpen0 the lambda resource accepts either filename or s3_bucket and s3_key. You can use the filename instead, provide it with some dummy file, and add filename to ignore_changes

@Logan Stuart
You can just have a dummy zip with a hello world script in with your TF and
use the lifecycle with ignore_changes and the initial run of TF to stand-up
and modify Lambda function infra will be separated from the builds you run
via your CI/CD process. This work around has been functioning well for my
own need to separate infra from code deployment process in Lambda.

Regards,
David Gotlieb
System Engineer
CMS Ops & Engineering
480-220-3126

On Wed, May 29, 2019 at 9:49 AM Logan Stuart notifications@github.com
wrote:

@AbdulRahmanAlHamali
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_AbdulRahmanAlHamali&d=DwMCaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=pxjCP5xMvnqaI0OniuvhKKx93JGHSmWeSddVaYk10nM&s=E_J4gr0cSAASjBRFkLpNVEluMF-Vv9kjS9_-D8PL_3A&e=
Yes, this is the workaround I use now. Unfortunately, providing an empty
zip file or a dummy file is rejected by terraform on a brand new lambda so
I have to keep a zip file with actual files inside of it in my repo for
launching new lambdas.

I will reiterate this: The AWS API formally allows the creation of empty
lambdas
and terraform is being overly opinionated on how I am supposed
to use lambda.

I do not deploy application code with terraform, code is deployed with
code deployment tools. I manage infrastructure with terraform. I create a
lambda and surrounding resources in terraform and developers deploy code to
that lambda in my deployment pipelines where they are provided restricted
credentials that are only able to edit the code and not the surrounding
infrastructure.

Imagine if the S3 module forced you to upload files and didn't let you
make an empty bucket or if the EC2 module forced you to provide a binary of
the application to run on the host or if the RDS module forced you to
provide a migration script and never let you launch an empty database.
Nobody would use terraform in that world. That's basically what the lambda
module is forcing me to do and that is why it is ridiculous.

โ€”
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_terraform-2Dproviders_terraform-2Dprovider-2Daws_issues_5945-3Femail-5Fsource-3Dnotifications-26email-5Ftoken-3DAF6VUT36ZY5UZDHUHN2R6ULPX2X2ZA5CNFSM4FWJOERKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWP6OOQ-23issuecomment-2D497018682&d=DwMCaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=pxjCP5xMvnqaI0OniuvhKKx93JGHSmWeSddVaYk10nM&s=nWe_OLv-AOJlw94zFHglfKN2361r5mkAO98HD78k13w&e=,
or mute the thread
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AF6VUTYMWJDHN74NONCQ3Y3PX2X2ZANCNFSM4FWJOERA&d=DwMCaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=HJx-meNOSHgDLuhXd6bWtLxh3vyeX8NyRGZIibhyEH8&m=pxjCP5xMvnqaI0OniuvhKKx93JGHSmWeSddVaYk10nM&s=XcrbXpXbDfeKwLxosKS8kvaDmShkvN6pmoeyHbjkiGg&e=
.

Was this page helpful?
0 / 5 - 0 ratings