Asg additional block devices

[qrilka]

---

name: Pull request template about: Make a PR to terraform-aws-foundation

Please include the following in your PR:

Please also note that these are not hard requirements, but merely serve to define what maintainers are looking for in PR's. Including these will more likely lead to your PR being reviewed and accepted.

• [ ] Update the changelog
• [ ] Make sure that modules and files are documented. This can be done inside the module and files.
• [ ] Make sure that new modules directories contain a basic README.md file.
• [ ] Make sure that the module is added to tests/main.tf
• [ ] Make sure that the linting passes on CI.
• [ ] Make sure that there is an up to date example for your code:
  • For new modules this would entail example code for how to use the module or some explanation in the module readme.
  • For new examples please provide a README explaining how to run the example. It's also ideal to provide a basic makefile to use the example as well.
• [ ] Make sure that there is a manual CI trigger that can test the deployment.

[ketzacoatl]

This change LGTM. Let's get it tested, merged, and released.

[qrilka]

I see additional block device available in out current project, do we need some additional testing here? I wanted to add a line into the changelog but I guess it makes sense to address #248 first

[qrilka]

@ketzacoatl we use this module for quite some time already and it seems to work fine. Are there any additional steps required to get this merged?

[ketzacoatl]

@qrilka apologies for overlooking the previous question. Can you paste/screenshot/etc a working example/etc that demonstrates the update is functional? That is what we're looking for in general, for all PRs (demonstrate the update works in common use cases, and doesn't break existing use by surprise).

[ketzacoatl]

Should I create a separate ASG in dev-sandbox?

Deploying an ASG to dev-sandbox is fine to do, sure.

Deploying the gitlab example ought to be a good test as well, that should be using all the pieces here and give you an easy way to confirm correctness/functioning. Using an ASG of your own is also ok if you prefer.

Will a plan be enough?

A plan is a good start, though that's not as ideal as a full test.

I'd even argue it's worth hooking up the gitlab or another couple examples to our Gitlab for CI and make the test easier to run a lot. We started down this path for foundation in the past (with some S3 tests), but we stopped short. I have also set this up for past projects (the legacy vpc example was one), and it worked sooooo great, I loved having that feedback. If we want to hookup one or more of the examples to Gitlab, we should scope that out in a new ticket.

[qrilka]

@ketzacoatl Gitlab examples seem to be not sufficient here as they don't use asg directly and also they don't use this new feature. So I went with a custom Terraform file - https://gist.github.com/qrilka/4e1f674ee28bd348e24fc3bd10318688

The resulting instances with (or without) extra EBS could be seen at https://imgur.com/a/4Q064jt

[psibi]

@qrilka / @ketzacoatl While we add volumes to it, this doesn't attach the volumes to the instances in the ASG. Also, it seems (for valid reasons) we can attach an ebs volume to only one instance at a time. Do you think we should handle this also ?

[qrilka]

@psibi EBS volume specified in a launch configuration creates a new one and attaches it automatically. See e.g. "Additional EBS block devices to attach to the instance. " for ebs_block_device at https://www.terraform.io/docs/providers/aws/r/launch_configuration.html With a launch configuration you attach a volume at launch time. I guess in your question with "attaching" you mean doing that at runtime (even during init)?

[ketzacoatl]

w/ Additional EBS Volumes:

No Additional Volumes: