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

Allow to pass parameter value for 'Enabled' property in ScheduledEvent of 'AWS::Serverless::Function' #1329

Closed
jeswanthamazon opened this issue Dec 16, 2019 · 25 comments

Comments

@jeswanthamazon
Copy link

When you reference a parameter for 'Enabled' property in ScheduledEvent of 'AWS::Serverless::Function', it is not honoring the parameter value passed and setting the "State": "ENABLED" for Events::Rule in the processed template.

'Enabled' property in ScheduledEvent of 'AWS::Serverless::Function' currently only accepts 'true' or 'false' bool values hard-coded as string in template.

in the background when composing the processed template, 'AWS::Serverless-2016-10-31' transform sees:

Currently Serverless transform is not capable of reading the parameter value to set the 'State' of Event::Rule.

Please add support to parse the parameter value and set the 'State' property value to 'DISABLED' /'Enabled' accordingly.

@SydneyUni-Jim
Copy link

This is related to #1360

@praneetap
Copy link
Contributor

Thanks for the issue report! We have passed this along to our product team for possible prioritization. Please +1 on the feature to help with prioritization.

@jfuss jfuss added the stage/pm-review Waiting for review by our Product Manager, please don't work on this yet label Aug 7, 2020
@RichieRunner
Copy link

RichieRunner commented Oct 9, 2020

It has been 10 months, when is this going to be fixed? Even Enabled: False doesn't even work anymore.

@jwalsh2me
Copy link

@jfuss is this still under review?

@RichieRunner
Copy link

this is such a shame. you have a core feature broken, and nobody who's paid to work on it even cares.

@z0ph
Copy link

z0ph commented Nov 24, 2020

Same issue here, lost a few hours on troubleshooting this...

@RichieRunner
Copy link

Since it's abundantly clear now that AWS and the maintainers of this codebase are refusing to prioritize this to be a critical bug, what is everyone's recommendation for disabling the Enabled flag if you are building resources in NP?

I am trying to achieve this kind of conditional logic:
image

@z0ph
Copy link

z0ph commented Nov 27, 2020

Since it's abundantly clear now that AWS and the maintainers of this codebase are refusing to prioritize this to be a critical bug, what is everyone's recommendation for disabling the Enabled flag if you are building resources in NP?

I am trying to achieve this kind of conditional logic:
image

Same here, what do you think @RichieRunner if we switch to the standard CloudFormation template (not SAM), should it be fine?

@jwalsh2me
Copy link

jwalsh2me commented Nov 27, 2020 via email

@awsjeffg
Copy link

@RichieRunner @z0ph @jwalsh2me thanks for bumping this issue and discussing workarounds. I've just now added this to the backlog internally, and I apologize that we struggle with communicating status on issues like this where there are internal and external trackers involved.

Is there a workaround people have found for this particular issue? I was hoping for some cases like this that SAM CLI's recent addition of environments would help, but I can see why it fails here.

@jewelsjacobs
Copy link

A workaround would be much appreciated. I'm running into the same issue using the same Condition logic.

@z0ph
Copy link

z0ph commented Nov 30, 2020

Hi there,

Do you think we can apply similar logic to the parent lambda event source?

image

I don't know where we can set this up in SAM. Any clues ?

@jewelsjacobs
Copy link

FWIW, I have a bash script function workaround. It will remove the lambda CloudWatch Event rule trigger and disable the rule itself for SAM rules with the default serverlessrepo*. names. It should be easy to add parameters / variables to.

I can't find an AWS CLI way to just disable a CloudWatch Event in the Lambda so I remove it.

https://gist.github.com/jewelsjacobs/2ea1b37dd4db5279d038111e77d9d813

@RichieRunner
Copy link

FWIW, I have a bash script function workaround. It will remove the lambda CloudWatch Event rule trigger and disable the rule itself for SAM rules with the default serverlessrepo*. names. It should be easy to add parameters / variables to.

I can't find an AWS CLI way to just disable a CloudWatch Event in the Lambda so I remove it.

https://gist.github.com/jewelsjacobs/2ea1b37dd4db5279d038111e77d9d813

Thanks, so...you just run this as a last step in every build? 😖

@jewelsjacobs
Copy link

Thanks, so...you just run this as a last step in every build? 😖

Pretty much @RichieRunner 😞

@diegogurpegui
Copy link

+1 waiting for a fix

@victor
Copy link

victor commented Jan 21, 2021

@jwalsh2me I don't know what you're talking about

@nbrational
Copy link

nbrational commented Jan 28, 2021

I could work around this by adding a separate resource for AWS::Events::Rule and excluded 'Events' property from AWS::Serverless::Function. Example template:-

Transform: AWS::Serverless-2016-10-31
Description: >
  sam-app

  Sample SAM Template for sam-app

Globals:
  Function:
    Timeout: 3

Parameters:
  RuleEnabled:
    Description: ENABLED or DISABLED
    Default: ENABLED
    Type: String
    # AllowedValues: [True, False]

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello_world/
      Handler: app.lambda_handler
      Runtime: python2.7
      # Events:
        # HelloWorld:
        #   Type: Api # More info about API Event Source: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
        #   Properties:
        #     Path: /hello
        #     Method: get
        # ScheduledEvent:
        #   Type: Schedule
        #   Properties:
        #     Schedule: cron(30 3 * * ? *)
        #     Description: Execute the application as batch (Run at 9:00 am (UTC) every day)
        #     Enabled: !Ref RuleEnabled

  HelloWorldFunctionScheduledEvent:
    Type: AWS::Events::Rule
    Properties:
      State: !Ref RuleEnabled
      ScheduleExpression: cron(30 3 * * ? *)
      Description: Execute the application as batch (Run at 9:00 am (UTC) every day)
      Targets:
      - Id: HelloWorldFunctionScheduledEventLambdaTarget
        Arn:
          Fn::GetAtt:
          - HelloWorldFunction
          - Arn

@RichieRunner
Copy link

I could work around this by adding a separate resource for AWS::Events::Rule and excluded 'Events' property from AWS::Serverless::Function. Example template:-

Ahh, that's smart! This is worth a try as well, thanks!

@z0ph
Copy link

z0ph commented Mar 29, 2021

I could work around this by adding a separate resource for AWS::Events::Rule and excluded 'Events' property from AWS::Serverless::Function. Example template:-

It's working as a workaround. Thanks @nbrational

@forzagreen
Copy link
Contributor

I could work around this by adding a separate resource for AWS::Events::Rule and excluded 'Events' property from AWS::Serverless::Function. Example template:-

Thank you @nbrational for the workaround.

I think you also have to grant Events the permission to invoke the lambda, using AWS::Lambda::Permission resource :

  HelloWorldFunctionLambdaPermission:
    Type: AWS::Lambda::Permission
    Properties:
      Action: lambda:InvokeFunction
      FunctionName: !GetAtt HelloWorldFunction.Arn
      Principal: events.amazonaws.com
      SourceArn: !GetAtt HelloWorldFunctionScheduledEvent.Arn

@RichieRunner
Copy link

Closing in on the 2 year mark with still no fix from the SAM team on this 🎉

@jfalkenstein
Copy link

Could we please get some attention on this?

@jfuss
Copy link
Contributor

jfuss commented Jun 16, 2022

Hey all, I am moving through our backlog of PRs and this PR (#1666) was looking to address this.

I am in the middle of updating it but realized a couple things, if you are using Intrinsic Functions as the value, this will break because SAM expects "true" or "false" while the underlying CFN resource uses "enabled" or "disabled".

SAM's history with intrinsic functions are hit or miss. Mostly due to us needing to re-implement how CloudFormation handles these, as there is no library provided by CloudFormation. Instead of going down that path (which has a bunch of flaws/concerns), I am thinking about adding a new property that will be a passthrough to the underlying CloudFormation resource directly. This would require customers to change their templates but existing ones would behave the same and people running into issues (as described here) could be unblocked.

Looking for some thoughts from the community on this.

@jwalsh2me
Copy link

I like the idea of a new property!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests