Closed pearkes closed 8 years ago
Other services I'm currently using CloudFormation for: Dynamo and ElasticBeanstalk
Does Route53 work with Aliases?
Also, what about tags and EBS volumes/snapshots?
@AlexanderEkdahl as of now, no. Added to the list.
What about configuring OpsWorks stacks?
@nirev Added to the list!
How does mitchellh/goamz compare to the other goamz forks? From what I can see there are other forks which provides more features.
I'd like to be able to start an EC2 instance with an assigned IAM role, this would really help with keeping security credentials out of templates/scripts.
SSL support for ELBs should be a priority IMO as well.
@rosstimson Yea, I think SSL is definitely a priority too.
I added IAM roles to the list. It's already in goamz so should be pretty easy.
What's the consensus on providing pull-requests for aspects of this issue? Create a new issue to start a discussion on how to approach the problem or flesh out a solution, open a PR and have the discussion there?
I got time over the weekend to implement block device mappings but I'd like to synchronize regarding the update semantics as well as on how much magic (if at all) should be applied for things like DeviceName
mapping or (potentially) automatic ephemeral storage mapping.
@yawn PR is preferable if there's any code involved, happy to talk things out there. You can also find us on Freenode in #terraform-tool
.
Ok!
SSL for ELBs are my major feature request, so I guess it's time to go have a poke through some Go code!
Hey guys - this is a great list and I appreciate the emphasis on AWS features.
I've been looking at my CloudFormation templates and one implicit item that keeps appearing is the need to support VPC features with many of the API items, such as EC2, ElastiCache, RDS, ELB, etc. This includes using VPC security groups.
Under ElastiCache, similar to RDS, is the need to support SubnetGroups.
Otherwise, my priorities are SSL with ELB, ElastiCache, and EC2 subitems like tags, IAM roles, auto-scaling, and the ElastiCache/RDS subnet groups.
I'll help as I can.
@brianknight10 Thanks for the input! You're right, although there is relatively strong support in the providers for VPC features, there are definitely still gaps. I've updated the list with some of your suggestions.
How about support for EBS volumes? I'd like to define an EBS volume to attach to an instance, and when I apply a plan that rebuilds the instance, it will reattach the volume. This would give us the ability to persist certain data.
@kief Added. Nice idea!
EC2 security groups should be able to take egress
blocks as well. However, we'll run into a problem with mutually dependent security groups, e.g.
resource "aws_security_group" "foo" {
...
ingress {
...
security_groups = ["${aws_security_group.bar}"]
}
}
resource "aws_security_group" "bar" {
...
egress {
...
security_groups = ["${aws_security_group.foo}"]
}
}
CloudFormation solves this by introducing two new resource types, AWS::EC2::SecurityGroupIngress
and AWS::EC2::SecurityGroupEgress
. Barring more sophisticated dependency graph logic, I think we'll need something similar (aws_security_group_ingress
and aws_security_group_egress
), in addition to the ingress
and egress
blocks.
I've started on instance tags in #173 and I've implemented VPC DNS attributes in #172. I'd love some direction on how testing works with terraform so I can get these features completed.
@alekstorm that security group functionality would also fix a strange case I've seen a few times where security groups are considered in need of change because the ordering of the rules is different. I have a feeling that the ordering is actually not guaranteed on Amazon's side...
Okay, VPC tags are in #175. I've added a couple of generic functions for making things taggable, and that PR should show pretty clearly how to use them if anybody else wants to make some more things taggable sometime!
It might be a looking-for-milk-in-the-freezer-when-it's-right-in-front-of-you kind of situation, but I'm not seeing support for SNS on this list, which would be nice.
@tonnydourado Thanks, added SNS!
@deoxxa Thanks for all your PRS and contributions! Pending some of that set stuff we hope to get it all in.
+1 for EBS volume support. If anyone else is mounting volumes, I'm doing some manual stuff with the aws cli: https://github.com/whatupdave/blockway/blob/master/tf/main.tf
@pearkes IMHO, we should use the same approach AWS guys use to generate their other SDKs, by using these API declarations: https://github.com/aws/aws-sdk-core-ruby/tree/master/apis. It shouldn't be that difficult to do that and hopefully it will cover most of their services.
@c4milo: Corrected link: https://github.com/aws/aws-sdk-core-ruby/tree/master/aws-sdk-core/apis
But yeah... I wish there was a go aws library that would just use these service declarations. It would be much easier to keep up to date.
Adding a +1 for EC2 instance name and tagging. Would be super nice to have.
When Trying to setup a VPC instance I was getting: error: : invalid or unknown key: vpc_id. For instances, it seems like the correct thing to do is set is subnet_id and then vpc_id is inferred. I think the docs and examples could explain this better.
+1 for the EC2 instance name/tagging + EBS volume properties (type, encryption, etc.). Also, why not just allow the user to specify arbitrary key-value pairs that just get passed through the AWS API call? This way, when AWS inevitably releases their next big thing, there's always a shim available until Terraform has official support.
:+1: for route53 aliases
aws_security_group egress rules would be a big win, as well as breaking out the egress and ingress rules to their own types as @alekstorm has suggested. While looking to replace our existing cloudformation templates with terraform, the lack of these resources is actually a show stopper for us (unless there is some other creative way to accomplish this). We currently have rules that do the "self referencing" so that nodes within an sg can communicate with other nodes in the sg (and not much else). In case it helps a real world example is setting up a coreos cluster as outline in this cloudformation template: https://s3.amazonaws.com/coreos.com/dist/aws/coreos-stable-hvm.template
@dpetzel: re: ingress/egress rules referring to the containing security group in coreos cluster setup, you can use two security groups, similarly to how @alekstorm suggested above:
resource "aws_security_group" "base" {
...
# allow ssh from where?
ingress {
...
cidr_blocks = ["${var.allowSSHFrom}"]
}
}
resource "aws_security_group" "standard" {
...
# etcd api
ingress {
...
security_groups = ["${aws_security_group.base}"]
}
}
Then add both security groups to your launch configuration, and you should be off and running (I have it working, so if it doesn't work as described, ask away).
Another gap in the VPC stack appears to be managing network ACLs, associating them with subnets and managing ACL entries.
:+1: for tags
:+1: for tags
:thumbsup: for tags
What they said ^^^
Added DB subnet group in this pull request https://github.com/hashicorp/terraform/pull/295.
:+1: for tags
@pearkes +1 on Redshift support
@bilalaslam Added, thanks!
:+1: for tags
I believe this pull request, https://github.com/hashicorp/terraform/pull/303, is the last missing piece for full VPC support for the AWS ELB resource.
New zones need to have NS records in their parent zones https://github.com/hashicorp/terraform/issues/305
Support for setting IAM instance profile when launching AWS instances is in #319
Yay for Tags and IAM Roles!
Support for ELB listener SSL certificate is in #350
Tags just got done, slowly adding them to more resources now.
AWS Provider Coverage
View this spreadsheet for a near-time summary of AWS resource coverage. If there's a resource you would like to see coverage for, just add your GitHub username to next to the resource. We will use the number of community upvotes in the spreadsheet to help prioritize our efforts.
https://docs.google.com/spreadsheets/d/1yJKjLaTmkWcUS3T8TLwvXC6EBwNSpuQbIq0Y7OnMXhw/edit?usp=sharing