pearkes commented 10 years ago

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

zwily commented 10 years ago

Other services I'm currently using CloudFormation for: Dynamo and ElasticBeanstalk

AlexanderEkdahl commented 10 years ago

Does Route53 work with Aliases?

MrJoy commented 10 years ago

Also, what about tags and EBS volumes/snapshots?

pearkes commented 10 years ago

@AlexanderEkdahl as of now, no. Added to the list.

vertis commented 10 years ago

103 adds support for using ELBs within a VPC and for the internal argument

nirev commented 10 years ago

What about configuring OpsWorks stacks?

pearkes commented 10 years ago

@nirev Added to the list!

AlexanderEkdahl commented 10 years ago

How does mitchellh/goamz compare to the other goamz forks? From what I can see there are other forks which provides more features.

rosstimson commented 10 years ago

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.

pearkes commented 10 years ago

@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.

yawn commented 10 years ago

Rootvolume size and type, volumes in general, ephemeral storage, encryption etc.
Tags everywhere possible (not just EC2)

yawn commented 10 years ago

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.

pearkes commented 10 years ago

@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.

yawn commented 10 years ago

Ok!

girvo commented 10 years ago

SSL for ELBs are my major feature request, so I guess it's time to go have a poke through some Go code!

brianknight10 commented 10 years ago

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.

pearkes commented 10 years ago

@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.

kief commented 10 years ago

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.

pearkes commented 10 years ago

@kief Added. Nice idea!

alekstorm commented 10 years ago

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.

deoxxa commented 10 years ago

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.

deoxxa commented 10 years ago

@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...

deoxxa commented 10 years ago

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!

tonnydourado commented 10 years ago

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.

pearkes commented 10 years ago

@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.

whatupdave commented 10 years ago

+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

c4milo commented 10 years ago

@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.

zwily commented 10 years ago

@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.

seanherron commented 10 years ago

Adding a +1 for EC2 instance name and tagging. Would be super nice to have.

daleki commented 10 years ago

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.

josh-padnick commented 10 years ago

+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.

levinotik commented 10 years ago

:+1: for route53 aliases

dpetzel commented 10 years ago

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

emmanuel commented 10 years ago

@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).

icebourg commented 10 years ago

Another gap in the VPC stack appears to be managing network ACLs, associating them with subnets and managing ACL entries.

zxjinn commented 10 years ago

:+1: for tags

levinotik commented 10 years ago

:+1: for tags

joshcody commented 10 years ago

:thumbsup: for tags

robparrott commented 10 years ago

What they said ^^^

buth commented 10 years ago

Added DB subnet group in this pull request https://github.com/hashicorp/terraform/pull/295.

girvo commented 10 years ago

:+1: for tags

bilalaslam commented 10 years ago

@pearkes +1 on Redshift support

pearkes commented 10 years ago

@bilalaslam Added, thanks!

marshyski commented 10 years ago

:+1: for tags

buth commented 10 years ago

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.