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

[PLAT-71] Allow define one optional volume #3

Merged
merged 6 commits into from
Jun 1, 2017
Merged

Conversation

keymon
Copy link
Contributor

@keymon keymon commented May 25, 2017

Note: same as #2 fixing spurious content

For some cases and workloads we need to pass some modules to the task definition. The volumes are passed as a list of maps to the ecs_task_resource[1].

But the current syntax of terraform does not allow consume this value directly from a variable. Trying to do so, we hit the issues described in [2] and [3] (pending to report a specific bug).

But we found out that it works if we build the map structure directly within the resource, and we use interpolation to consume the values of the map.

Meanwhile the terraform project does not provide a definitive solution, we
will implement the following workaround:

  • The module will receive configuration for one unique module, being the default a empty map {}
  • If the map is empty, a dummy volume will be passed as name=dummy and host_path=/tmp/dummy_volume

This would cover our specific case in the short term, and can be later easily adapted to use a optional list of volumes.

[1] https://www.terraform.io/docs/providers/aws/r/ecs_task_definition.html#volume
[2] hashicorp/terraform#10407
[3] hashicorp/terraform#7705 (comment)

keymon added 2 commits May 25, 2017 12:53
For some cases and workloads we need to pass some modules to the task
definition. The volumes are passed as a list of maps to the
ecs_task_resource[1].

But the current syntax of terraform does not allow consume this value
directly from a variable. Trying to do so, we hit the issues described
in [2] and [3] (pending to report a specific bug).

But we found out that it works if we build the map structure directly
within the resource, and we use interpolation to consume the values of
the map.

Meanwhile the terraform project does not provide a definitive solution,
we will implement the following workaround:

 - The module will receive configuration for one unique module, being
   the default a empty map {}
 - If the map is empty, a dummy volume will be passed as `name=dummy`
   and `host_path=/tmp/dummy_volume`

This would cover our specific case in the short term, and can be later
easily adapted to use a optional list of volumes.

[1] https://www.terraform.io/docs/providers/aws/r/ecs_task_definition.html#volume
[2] hashicorp/terraform#10407
[3] hashicorp/terraform#7705 (comment)
keymon added a commit to mergermarket/tf_ecs_task_definition_with_task_role that referenced this pull request May 25, 2017
keymon added a commit to mergermarket/tf_ecs_task_definition_with_task_role that referenced this pull request May 25, 2017
Meanwhile [1] is not merge, point to that branch to allow review and
test this PR. Revert once [1] is merged.

[1] mergermarket/tf_ecs_task_definition#3
In order to avoid creating spurious files in the current directory
(.terraform and __pycache__) we run terraform in a temporary directory
within the container and we disable python bytecode generation by
setting PYTHONDONTWRITEBYTECODE env var.

https://docs.python.org/2/using/cmdline.html#envvar-PYTHONDONTWRITEBYTECODE

Also cleanup test code
Copy link
Contributor

@bart613 bart613 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some small bits for your consideration to tweak. Otherwise solid stuff 👍

README.md Outdated
@@ -23,6 +23,8 @@ This module creates a basic ECS Task Definition.

* `family` - the name of the task definition. For ECS services it is recommended to use the same name as for the service, and for that name to consist of the environment name (e.g. "live"), the comonent name (e.g. "foobar-service"), and an optional suffix (if an environment has multiple services for the component running - e.g. in a multi-tenant setup), separated by hyphens.
* `container_definitions` - list of strings. Each string should be a JSON document describing a single container definition - see https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html.
* `task_role_arn` - The Amazon Resource Name for an IAM role for the task.
* `volume` - Volume block map with 'name' and 'host_path'. 'name': The name of the volume as is referenced in the sourceVolume. 'host_path' The path on the host container instance that is presented to the container.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This, again, I'd consider shortening description here and refer to full documentation with example

@@ -16,11 +16,18 @@ variable "task_role_arn_param" {
default = ""
}

variable "task_volume_param" {
description = "Allow the test to pass this in"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Elaborate.

type = "map"
default = {}
}

module "taskdef" {
source = "../.."

family = "tf_ecs_taskdef_test_family"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

terraform fmt this bit of code please

@@ -1,32 +1,45 @@
import re
import unittest
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isort

self.module_path = os.path.join(os.getcwd(), 'test', 'infra')

check_call(
['terraform', 'get', self.module_path],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this not fit on a single line?

variables.tf Outdated
@@ -13,3 +13,9 @@ variable "task_role_arn" {
type = "string"
default = ""
}

variable "volume" {
description = "Volume block map with 'name' and 'host_path'. 'name': The name of the volume as is referenced in the sourceVolume. 'host_path' The path on the host container instance that is presented to the container."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider shortening description and refer to README

keymon added 3 commits June 1, 2017 10:34
Make the description shorten and refer to the original documentation.
@keymon
Copy link
Contributor Author

keymon commented Jun 1, 2017

@bart613 👍 thx, I applied the suggested changes

@keymon keymon merged commit 5146979 into master Jun 1, 2017
@keymon keymon deleted the PLAT-71_add_volume_2 branch June 1, 2017 11:30
keymon added a commit to mergermarket/tf_ecs_container_definition that referenced this pull request Jun 6, 2017
For some cases and workloads we need to pass some mountpoints to the container
definition. The mountpoints are passed as a list of maps in the json under
`mountPoints`[1].

In the related modules tf_task_definition, we added logic to define one
optional volume[2], and here we allow to specify the mounpoint for that
volume.

The mountpoint is defined as a map with the keys `sourceVolume`,
`containerPath` and (optional) `readOnly` .

[1] http://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_storage
[2] mergermarket/tf_ecs_task_definition#3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants