quintilesims / layer0

Build, Manage, and Deploy Your Applications
Apache License 2.0
44 stars 20 forks source link

Layer0 v0.10.4 #489

Closed nehayward closed 6 years ago

nehayward commented 6 years ago

If the current version of a user's layer0 (as defined in ~/.layer0//main.tf.json) is not semver compliant, this change will notify the user that they can use the --force flag to override the message.

Unit tests were failing because of very old semver version of this package Forced it to constrain to the master branch of the project

I created three tf modules, environment, service and deploy. The outputs of environment and deploy are picked up by service. Services are distributed using element() amongst available environments and deploys.

Benchmark tests are no longer in table testing pattern Dockerrun.aws.json now correctly interpolates the command passed to it by the test Directory cleanup and organizing of the tf modules

The benchmark tests now allow creating an arbitrary number of load balancers in a given test Also made some adjustments to the dimensions of the benchmark tests themselves

Recognizes the environment variables LAYER0_AWS_TIME_BETWEEN_REQUESTS and LAYER0_AWS_MAX_RETRIES.

LAYER0_AWS_TIME_BETWEEN_REQUESTS is a time duration for the min amount of time allowed between AWS requests

LAYER0_AWS_MAX_RETRIES is a numerical value representing the max number of times a request will be retried for failures

The AWS Region specified when creating a layer0 instance is now output when running the command l0-setup endpoint -d.

Fixes an AMI ID for the API module in the us-east-1 region

The methods called in the AWS SDK that pull back Task Definitions should only be retrieving Task Definitions that are active. Without filtering Task Definitions by status, inactive Task Definitions can still be retrieved. For Layer0 instances that have been up for a long time, inactive Task Definitions can accumulate and has been known to slow the operation l0 deploy list down considerably.

When a new AWS Provider needs to be created, aws.Config needs to contain the correct region for interactions with AWS to work.

In the case where l0 instances are initialized and set up in a region other than the default us-west-2, the resources will create in the region specified in the init wizard, but pushing terraform state to the S3 bucket fails because it was always assumed that the AWS region would be us-west-2.

To fix this, anytime an AWS Provider is needed, the instance derives what region it's in (assuming that l0-setup apply ran to completion), and then passes that region into the AWS Provider helper function so that aws.Config sets the correct region for API operations via the WithRegion() method.

To solve the problem where a user might need to pull a remote layer0 instance but doesn't have the instance locally, we need to calculate the region the bucket is in before we actually pull from the bucket.

Two helper functions are created to help with this: one to retrieve a list of S3 buckets then match the associated bucket with the one provided by the user as the instance name, and one to determine the matched bucket's region.

What does this pull request do? Include a short summary of what this PR intends to fix and/or a reference to an existing issue.

How should this be tested? Include steps to test intended functionality.

Checklist

closes # (reference the issue(s) this pull request closes)