[WIP] 500: Set LaunchType for services and tasks; remove EnvironmentType from environments

[tlake]

What does this pull request do? Provides a solution for #500 that adds a --stateful boolean flag to the CLI's service create and task create to indicate a user's intent to launch on EC2 or Fargate instances. A similar flag is provided for the Terraform plugin. As a side effect, this changeset also removes the EnvironmentType (= "static" or "dynamic") field from the Environment model.

CLI and Terraform plugin read events have also been updated to understand the concept of a service or task's statefulness.

A user should specify requiresCompatibilities in the task definition file at the time of Deploy creation, and AWS will evaluate the task definition's compatibilities when it is registered in the course of Deploy creation. If a user fails to specify any requiresCompatibilities, Layer0 will supply both "EC2" and "FARGATE". In order for a service or task to be considered FARGATE-compatible (or "stateless"), a few additional fields must be configured in the task definition - see the Notes below.

How should this be tested?

• Create deploys from task definitions that have various combinations of "EC2" and "FARGATE" in the top-level requiresCompatibilities field and verify that the resulting deploy prints out the correct COMPATIBILITIES ("stateful" for EC2, "stateless" for FARGATE). Then, create service and tasks from the new deploys and provide various valid and invalid declarations of the --stateful flag. It seems that AWS will always check for EC2 compatibility, but will only check for Fargate compatibility when explicitly told to do so. Since "networkMode": "awsvpc" logic has been decoupled from the launch type, I think that most any Fargate-compatible deploys should work with stateful services and tasks.
  • l0 service create --stateful env-name svc-name ec2-dpl:latest should succeed ✅
  • l0 service create --stateful env-name svc-name fargate-dpl:latest should succeed ✅
  • l0 service create env-name svc-name ec2-dpl:latest should fail ❌
  • l0 service create env-name svc-name fargate-dpl:latest should succeed ✅
• Verify that the Terraform plugin functions as expected
• Verify that unit tests pass

The smoketests have been updated for the new workflow, and updated task definitions have been provided. That's probably a good place to gain understanding of the sort of workflows to use in manual testing.

Notes:

• Fargate is only available in us-east-1 right now, so make sure that's set in l0-setup.
• I've pushed an API binary to dockerhub: specify tlaketest in l0-setup.
• There are some requirements for a task definition file to be Fargate-compatible. Probably the most notable are the following four parameters (defined at the same level as "containerDefinitions"):

  "requiresCompatibilities": [ "FARGATE" ], 
  "networkMode": "awsvpc", 
  "cpu": "256", 
  "memory": "0.5GB",

  More info at https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html - in particular, note that there are specific values allowed for "cpu" and "memory".

• Effort has been made to be as hands-off as possible in error handling. Because Fargate is so new, it is likely pointless to anchor Layer0 to its current implementation, and so Layer0 will by and large do what the user tells it do and then pass along any AWS errors that arise. These errors seem to be relatively helpful; it would be a good idea to keep an eye out for any error messages which are confusing or opaque, and also to verify that expected AWS errors are arising.

Checklist

• [x] Unit tests
• [x] Smoke tests (if applicable)
• [ ] System tests (if applicable)
• ~[ ] Documentation (if applicable)~ (a separate issue exists for documentation, which will be undertaken once a path for launch types has been greenlit)

closes #500

[zpatrick]

@tlake: don't forget to update swagger models!

[tlake]

@diemonster I'm happy to touch on smoketests in this PR. I haven't devoted any time to them yet because I wanted to not waste energy on them if this turned out to be the wrong path to follow. However, I know we've been wanting to get this into api-refactor ASAP, so messing with smoketests would definitely delay that.

Another option might be to merge this once code review has passed so that other devs can incorporate these changes in their own work, and then I can do smoketests in the same PR in which I add documentation for this new launch type support.

[nehayward]

Could we list whether the env is fargate or ec2 in the ‘l0 environment list command’

[tlake]

Closing this for now to avoid clutter.