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

sam incorrectly resolve parameters #1360

Closed
mgorski-mg opened this issue Jan 3, 2020 · 11 comments
Closed

sam incorrectly resolve parameters #1360

mgorski-mg opened this issue Jan 3, 2020 · 11 comments
Labels
area/intrinsics Ref, If, Sub, GetAtt, ... type/feature

Comments

@mgorski-mg
Copy link

I have a problem to pass parameters to enable or disable Lambda Scheduler

Template:

Parameters:
  SchedulerCronParameter:
    Type: String
    Description: Enter scheduler cron expresion. Default is cron(0 1 1 * ? *).
    Default: cron(0 1 1 * ? *)
  SchedulerEnabledParameter:
    Type: String
    Description: Enable or disable scheduler. Default is true.
    Default: true
    AllowedValues: [true, false]

Resources:
  ScheduledLambda:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: code/
      Handler: handler.lambda_handler
      Runtime: python3.7
      Timeout: 900
      Tracing: Active
      Events:
        Schedule:
          Properties:
            Name: LambdaScheduler
            Description: Monthly schedule
            **Enabled: !Ref SchedulerEnabledParameter**
            Schedule: !Ref SchedulerCronParameter
            Input: '{"view_only": false}'
          Type: Schedule

I think it's because the template is translated before resolving CF Parameters.
Code from SAM translator:

if self.Enabled is not None:
            events_rule.State = "ENABLED" if self.Enabled else "DISABLED"

If the Parameter is not resolved before translation, it's always set State as 'ENABLED'.

Do you have any workaround for it?

SAM CLI version: 0.39.0

@jfuss
Copy link
Contributor

jfuss commented Jan 3, 2020

@mgorski-mg Thanks for the issue. I think this has to do with how the spec works and not specifically the deploy command. I am going to forward this over to the SAM Translator (Spec) repo for further help.

@jfuss jfuss transferred this issue from aws/aws-sam-cli Jan 3, 2020
@mgorski-mg
Copy link
Author

@jfuss true that 😅 Thx!

@mgorski-mg mgorski-mg changed the title sam deploy incorrectly resolve parameters sam incorrectly resolve parameters Jan 5, 2020
@soccerboymalloy-patriot

Any updates or workarounds for this? We have a Lambda that we'd like to schedule in our Production account, but not in our Development account. We're trying to use TemplateConfiguration files in our CodePipeline in order to set this value. This bug is preventing us from disabling the schedule in our Development account.

I suppose we could define two Lambdas in our template (one with a schedule and one without) that get conditionally created based on the environment. But that's brittle, error prone, and ugly.

@mgorski-mg
Copy link
Author

mgorski-mg commented Jun 19, 2020

Any updates or workarounds for this? We have a Lambda that we'd like to schedule in our Production account, but not in our Development account. We're trying to use TemplateConfiguration files in our CodePipeline in order to set this value. This bug is preventing us from disabling the schedule in our Development account.

I suppose we could define two Lambdas in our template (one with a schedule and one without) that get conditionally created based on the environment. But that's brittle, error prone, and ugly.

You can define the scheduler using classic CloudFormation instead of the SAM.
You need to define AWS::Events::Rule and AWS::Lambda::Permission.
Then you can use parameters properly.

@soccerboymalloy-patriot

You can define the scheduler using classic CloudFormation instead of the SAM.
You need to define AWS::Events::Rule and AWS::Lambda::Permission.
Then you can use parameters properly.

Thanks for the pointer! Sometimes I forget that I can mix and match CloudFormation and SAM. For reference, this documentation is exactly what I needed.

@diegogurpegui
Copy link

I just came across this issue.
Any update or progress? or the solution at the moment is still the one suggested by @mgorski-mg?

@RichieRunner
Copy link

I just came across this issue.
Any update or progress? or the solution at the moment is still the one suggested by @mgorski-mg?

There's been no fix for this after 1 year, but there's a workaround discussed here

@ckabalan
Copy link

I just tried this today and it is still broken. The workaround by @mgorski-mg continues to work.

@jfuss jfuss added the area/intrinsics Ref, If, Sub, GetAtt, ... label Mar 29, 2022
@Yop-La
Copy link

Yop-La commented Apr 26, 2022

The same on my side. The issue is still here.

@hoffa
Copy link
Contributor

hoffa commented Oct 17, 2022

You might be able to get this to work by adding AWS::LanguageExtensions to Transform as such:

Transform:
  - AWS::LanguageExtensions
  - AWS::Serverless-2016-10-31

AWS::LanguageExtensions resolves intrinsic functions if the value is known when Transforms are run.

See #2533 for more information.

@hoffa
Copy link
Contributor

hoffa commented Nov 3, 2022

Closing in favor of #2533.

@hoffa hoffa closed this as completed Nov 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/intrinsics Ref, If, Sub, GetAtt, ... type/feature
Projects
None yet
Development

No branches or pull requests

10 participants