Onlycoldstarts #2
Conversation
| // run invocations in series | ||
| const {invocationResults, actualPayload} = await utils.invokeLambdaWithProcessors(lambdaARN, lambdaAlias, payloads[i], preARN, postARN); | ||
| if (onlyColdStarts){ | ||
| await utils.waitForAliasActive(lambdaARN, aliasToInvoke); |
There was a problem hiding this comment.
no try-catch needed here? if it's not needed, I'd remove it above too :)
There was a problem hiding this comment.
The one above was for debug purposes - I will remove both
lambda/initializer.js
Outdated
| }; | ||
|
|
||
| return powerValues; | ||
| module.exports.versionPublisher = async(event, context) => { |
There was a problem hiding this comment.
ideally this would be in a new file, to keep the one-function-per-file convention :)
| - Version: '2012-10-17' # allow Lambda actions | ||
| Statement: | ||
| - Effect: Allow | ||
| Action: |
There was a problem hiding this comment.
Let's check which of these actions are still needed for the Initializer function above.
I think now the initializer is only reading and the publisher is only writing?
lambda/initializer.js
Outdated
| for (let powerValue of powerValues){ | ||
| const baseAlias = 'RAM' + powerValue; | ||
| if (!onlyColdStarts){ | ||
| lambdaFunctionsToSet.push({lambdaARN: lambdaARN, powerValue: powerValue, envVars: envVars, alias: baseAlias}); |
There was a problem hiding this comment.
Splitting this logic into two separate function has a few security/privacy implications.
My concern here is that we are not only reading/modifying the environment variables of the given Lambda Function, but also passing them into the state machine input/output (and will likely end up into the overall state machine output too?). This could create complications when it comes to logging potentially sensitive variables/secrets to CloudWatch.
At the same time, I cannot think of a great alternative, besides refactoring this to be within the same Initializer function, with the same iterator logic, but then reading/updating the configuration on the spot.
In other words, instead of reading everything upfront to generate the full initConfigurations list, we would still iterate num times, and invoke utils.getLambdaPower and utils.createPowerConfiguration each time. I know it's a waste of time to invoke utils.getLambdaPower every time, but I think that's a better problem to have than passing around env variables & secrets.
| await utils.waitForFunctionUpdate(lambdaARN); | ||
|
|
||
| const {Version} = await utils.publishLambdaVersion(lambdaARN); | ||
| if (typeof alias === 'undefined'){ |
There was a problem hiding this comment.
This happens when we want to create a lambda version with the original power values (before Power Tuner modifications), and we don't want to setup an Alias for it (e.g. it'll be $LATEST)
There was a problem hiding this comment.
ok cool, I'd add a comment about it :) it will be harder to guess/remember in 6 months
Pull Request Test Coverage Report for Build 5070129290Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
|
Closing this PR, please refer to the PR on the main project repo alexcasalboni#206 |
3 participants
No description provided.