artilleryio / chaos-lambda Goto Github PK

It's best to only trigger failures when there are people around to fix them. Llama should only interfere with the environment during business hours (specifically Mon-Fri, 9:30am to 3pm - to allow for the morning coffee and to avoid being the reason someone would have to stay behind to fix a failure)

Was wondering if there was a reason its doing describe all instances instead of polling by Auto Scaling Group name using describeAutoScalingGroups?

Hi - trying to deploy this to my aws account; have everything setup on the AWS side and I am behind a corporate proxy; but I have set my HTTP-PROXY & HTTPS-PROXY env vars in my shell and can run the aws cli w/ out a problem, yet still receiving this error...any suggestions to get around this? thanks.

LIBP45P-16600WL:.aws n0224265$ llama deploy -r $LAMBDA_ROLE_ARN

Something went wrong:
{ Error: connect ETIMEDOUT 54.236.138.8:443
at Object.exports._errnoException (util.js:1022:11)
at exports._exceptionWithHostPort (util.js:1045:20)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1090:14)
message: 'connect ETIMEDOUT 54.236.138.8:443',
code: 'NetworkingError',
errno: 'ETIMEDOUT',
syscall: 'connect',
address: '54.236.138.8',
port: 443,
region: 'us-east-1',
hostname: 'lambda.us-east-1.amazonaws.com',
retryable: true,
time: 2017-03-16T18:55:39.380Z }

I think this is related to git and how nodejs deals with readFileSync() (but I may be wrong, I know a little about nodejs).

What I've done: I've cloned the repo, created a new branch, edited the code. When I re-deployed it (by typing chaos-lambda deploy -c Chaosfile.json) the relative code in the AWS Console didn't show the changes. Same goes while working in 'master' branch.

I had to remove the .git folder, made the changes and then deploy it.

I am beginner to AWS, I configured my node for llama-cli. I set the interval for 5 mins. I had 2 instances up and running in the ASG. But in CloudWatch logs I see that same instance was terminated multiple times. Can you please add why this happened. Asked by @shubhangi on https://recordnotfound.com/llama-cli-hassy-77433

Hey guys, really enjoying using this project.

Noticed you built a Slack integration in this PR: Add slack notification #21

It would be fantastic if the README details how I might be able to wire up Chaos Lambda running on my AWS account with my Slack. Any thoughts on how soon this can get done?

Hello, I'm getting this error when I try to execute chaos-lambda deploy ~~~~~
'The runtime parameter of nodejs6.10 is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (nodejs10.x) while creating or updating functions.',
code: 'InvalidParameterValueException'
Is there an updated code to fix this?

Thanks in advance,
EDIT: Updated the deploy.js file with nodejs10.x and now the issues is fixed. Thanks!

It would be useful to have Llama post to a Slack channel (with a Slack Webhook) to announce when an instance has been terminated.

1. The Slack webhook would be an option in Llamafile, e.g. slackWebhook
2. The lambda definition would use that (if defined) to post a message.

Hi,

Given the support of scheduling events to Lambda (AWS Lambda Schedules) is available in EU-West region, I'm wondering why would not chaos-lambda work in that region.

Can you please throw some light on this and advise if any other limitations that would hinder us using it full features in the region?

It should be possible to disable the llama for a while (e.g. for when a failure is being dealt with). It is currently possible with enableForASGs set to [] but there should be a convenient command for stopping the llama altogether.

The AWS api can return terminated instances for up to an hour. In cases of small server pool sizes, an instance that was already terminated could be returned to be "terminated" again.

👉 ZeroMQ's C4 Process, a collaboration model for free software projects that focuses on community success and shared ownership.

What needs to be done before we can say that we follow C4:

• Pre-commit hooks to run go fmt for Go, and eslint for JS code
• Add automated tests + CI integration

Add support in the Chaosfile.json to terminate instances by tags instead of names (implementing 'simianarmy.chaos.ASGtag.key' and 'simianarmy.chaos.ASGtag.value').

Our accounts are setup via an organisational accounts, with no users directly in development accounts. This is a common practice. Users switch role to desired accounts.

Perhaps this is the reason when deploying in a development account.

chaos-lambda deploy -r arn:aws:iam::50000000:role/ChaosLambda-Accessrole
AWS_REGION not set, defaulting to eu-west-1
Something went wrong:
{ AccessDeniedException: Cross-account pass role is not allowed.
    at Object.extractError (/usr/local/lib/node_modules/chaos-lambda/node_modules/aws-sdk/lib/protocol/json.js:43:27)
    at Request.extractError (/usr/local/lib/node_modules/chaos-lambda/node_modules/aws-sdk/lib/protocol/rest_json.js:37:8)
    at Request.callListeners (/usr/local/lib/node_modules/chaos-lambda/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
    at Request.emit (/usr/local/lib/node_modules/chaos-lambda/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/usr/local/lib/node_modules/chaos-lambda/node_modules/aws-sdk/lib/request.js:596:14)
    at Request.transition (/usr/local/lib/node_modules/chaos-lambda/node_modules/aws-sdk/lib/request.js:21:10)
    at AcceptorStateMachine.runTo (/usr/local/lib/node_modules/chaos-lambda/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /usr/local/lib/node_modules/chaos-lambda/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/usr/local/lib/node_modules/chaos-lambda/node_modules/aws-sdk/lib/request.js:37:9)
    at Request.<anonymous> (/usr/local/lib/node_modules/chaos-lambda/node_modules/aws-sdk/lib/request.js:598:12)
  message: 'Cross-account pass role is not allowed.',
  code: 'AccessDeniedException',
  time: 2019-06-21T13:53:13.545Z,
  requestId: 'e992148c-942b-11e9-9727-097a78ea9fd9',
  statusCode: 403,
  retryable: false,

The current CLI is written in Node.js (to help get a working version out quickly), however, as popular as Node.js is, it's not installed everywhere, and it's especially less likely to be installed on DevOps engineers machines (who would be the ones setting up Llama), which limits its appeal.

Going forward, the CLI should be rewritten in Go:

• A self-contained binary is easier to distribute - as a download or as a deb/rpm package
• There's an official AWS SDK for Go
• There's a number of solid libraries for building CLIs to make the job easier

👉 Llama Agent

• Add support for listing the ASGs for which the instances will have the agent running on them
• Add support for configuring VPC access

I was wondering how you would justify such a far-ranging authorization policy. In the code I only see ec2.describeInstances() and ec2.terminateInstances() being used. From what I can see, if I give those two -- and only those -- to my Lambda, it will work. So why would you say that full access is required?

InvalidParameterValueException: The runtime parameter of nodejs is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (nodejs4.3) while creating or updating functions.

Node 6.9

Im guessing im not alone here.