ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
terraform/website/source/layouts/aws.erb

603 lines
29 KiB
Plaintext
Raw Normal View History

website: fix typo
2014-09-16 15:54:53 +02:00
<% wrap_layout :inner do %>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<% content_for :sidebar do %>
<div class="docs-sidebar hidden-print affix-top" role="complementary">
<ul class="nav docs-sidenav">
<li<%= sidebar_current("docs-home") %>>
<a href="/docs/providers/index.html">&laquo; Documentation Home</a>
</li>
Add docs for various iam_* resources.
2015-04-23 16:24:45 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-index") %>>
<a href="/docs/providers/aws/index.html">AWS Provider</a>
</li>
Add docs for various iam_* resources.
2015-04-23 16:24:45 +02:00
provider/aws: Add docs for aws_cloudformation_stack
2015-07-07 00:45:47 +02:00
<li<%= sidebar_current(/^docs-aws-resource-cloudformation/) %>>
<a href="#">CloudFormation Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-cloudformation-stack") %>>
<a href="/docs/providers/aws/r/cloudformation_stack.html">aws_cloudformation_stack</a>
</li>
</ul>
</li>
Add docs for aws_iam_role
2015-05-12 23:09:46 +02:00
aws: Add docs for aws_cloudtrail
2015-08-28 00:25:29 +02:00
<li<%= sidebar_current(/^docs-aws-resource-cloudtrail/) %>>
<a href="#">CloudTrail Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-cloudtrail") %>>
<a href="/docs/providers/aws/r/cloudtrail.html">aws_cloudtrail</a>
</li>
</ul>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current(/^docs-aws-resource-cloudwatch/) %>>
<a href="#">CloudWatch Resources</a>
<ul class="nav nav-visible">
Add docs for various iam_* resources.
2015-04-23 16:24:45 +02:00
provider/aws: Add docs for CloudWatch Log Group
2015-09-16 23:02:45 +02:00
<li<%= sidebar_current("docs-aws-resource-cloudwatch-log-group") %>>
<a href="/docs/providers/aws/r/cloudwatch_log_group.html">aws_cloudwatch_log_group</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-cloudwatch-metric-alarm") %>>
<a href="/docs/providers/aws/r/cloudwatch_metric_alarm.html">aws_cloudwatch_metric_alarm</a>
</li>
Various AWS OpsWorks layer resource types. A "Layer" is a particular service that forms part of the infrastructure for a set of applications. Some layers are application servers and others are pure infrastructure, like MySQL servers or load balancers. Although the AWS API only has one type called "Layer", it actually has a number of different "soft" types that each have slightly different validation rules and extra properties that are packed into the Attributes map. To make the validation rule differences explicit in Terraform, and to make the Terraform structure more closely resemble the OpsWorks UI than its API, we use a separate resource type per layer type, with the common code factored out into a shared struct type.
2015-06-01 07:07:32 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
</ul>
</li>
Implement AWS IAM resources - Users - Groups - Roles - Inline policies for the above three - Instance profiles - Managed policies - Access keys This is most of the data types provided by IAM. There are a few things missing, but the functionality here is probably sufficient for 95% of the cases. Makes a dent in #28.
2015-02-06 16:34:24 +01:00
Added the documentation for the CodeCommit repository
2015-10-30 22:38:13 +01:00
<li<%= sidebar_current(/^docs-aws-resource-codecommit/) %>>
<a href="#">CodeCommit Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-codecommit-repository") %>>
<a href="/docs/providers/aws/r/code_commit_repository.html">aws_codecommit_repository</a>
</li>
</ul>
</li>
CodeDeploy links to the AWS provider sidebar. Missed these when merging #2783.
2015-10-21 17:44:19 +02:00
<li<%= sidebar_current(/^docs-aws-resource-codedeploy/) %>>
<a href="#">CodeDeploy Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-codedeploy-app") %>>
<a href="/docs/providers/aws/r/codedeploy_app.html">aws_codedeploy_app</a>
</li>
<li<%= sidebar_current("docs-aws-resource-codedeploy-deployment-group") %>>
<a href="/docs/providers/aws/r/codedeploy_deployment_group.html">aws_codedeploy_deployment_group</a>
</li>
</ul>
</li>
provider/aws: Add docs for aws_directory_service_directory
2015-09-13 18:58:22 +02:00
<li<%= sidebar_current(/^docs-aws-resource-directory-service/) %>>
<a href="#">Directory Service Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-directory-service-directory") %>>
<a href="/docs/providers/aws/r/directory_service_directory.html">aws_directory_service_directory</a>
</li>
</ul>
</li>
Implement AWS IAM resources - Users - Groups - Roles - Inline policies for the above three - Instance profiles - Managed policies - Access keys This is most of the data types provided by IAM. There are a few things missing, but the functionality here is probably sufficient for 95% of the cases. Makes a dent in #28.
2015-02-06 16:34:24 +01:00
Added the documentation for the CodeCommit repository
2015-10-30 22:38:13 +01:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current(/^docs-aws-resource-dynamodb/) %>>
<a href="#">DynamoDB Resources</a>
<ul class="nav nav-visible">
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-dynamodb-table") %>>
<a href="/docs/providers/aws/r/dynamodb_table.html">aws_dynamodb_table</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
</ul>
</li>
Docs: Sort AWS resources alphabetically
2015-05-30 16:36:04 +02:00
provider/aws: Add docs for aws_placement_group
2015-10-08 21:58:03 +02:00
<li<%= sidebar_current(/^docs-aws-resource-(app|autoscaling|ebs|elb|eip|instance|launch|lb|proxy|spot|volume|placement)/) %>>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<a href="#">EC2 Resources</a>
<ul class="nav nav-visible">
aws docs: Sort resources alphabetically
2015-06-13 22:12:24 +02:00
Three resources for AWS AMIs. AWS provides three different ways to create AMIs that each have different inputs, but once they are complete the same management operations apply. Thus these three resources each have a different "Create" implementation but then share the same "Read", "Update" and "Delete" implementations.
2015-08-30 06:35:45 +02:00
<li<%= sidebar_current("docs-aws-resource-ami") %>>
<a href="/docs/providers/aws/r/ami.html">aws_ami</a>
</li>
<li<%= sidebar_current("docs-aws-resource-ami-copy") %>>
<a href="/docs/providers/aws/r/ami_copy.html">aws_ami_copy</a>
</li>
<li<%= sidebar_current("docs-aws-resource-ami-from-instance") %>>
<a href="/docs/providers/aws/r/ami_from_instance.html">aws_ami_from_instance</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-app-cookie-stickiness-policy") %>>
<a href="/docs/providers/aws/r/app_cookie_stickiness_policy.html">aws_app_cookie_stickiness_policy</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-autoscaling-group") %>>
<a href="/docs/providers/aws/r/autoscaling_group.html">aws_autoscaling_group</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Adding the docs for the autoscaling_lifecycle_hook
2015-10-04 00:52:29 +02:00
<li<%= sidebar_current("docs-aws-resource-autoscaling-lifecycle-hook") %>>
Add support for aws autoscaling lifecycle hooks.
2015-09-29 08:09:45 +02:00
<a href="/docs/providers/aws/r/autoscaling_lifecycle_hooks.html">aws_autoscaling_lifecycle_hook</a>
Adding the docs for the autoscaling_lifecycle_hook
2015-10-04 00:52:29 +02:00
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-autoscaling-notification") %>>
<a href="/docs/providers/aws/r/autoscaling_notification.html">aws_autoscaling_notification</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-autoscaling-policy") %>>
<a href="/docs/providers/aws/r/autoscaling_policy.html">aws_autoscaling_policy</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-ebs-volume") %>>
<a href="/docs/providers/aws/r/ebs_volume.html">aws_ebs_volume</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-eip") %>>
<a href="/docs/providers/aws/r/eip.html">aws_eip</a>
</li>
Added docs, tests, and updated SQS code
2015-05-15 22:09:20 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-elb") %>>
<a href="/docs/providers/aws/r/elb.html">aws_elb</a>
</li>
Docs: Sort AWS resources alphabetically
2015-05-30 16:36:04 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-instance") %>>
<a href="/docs/providers/aws/r/instance.html">aws_instance</a>
</li>
Docs: Sort AWS resources alphabetically
2015-05-30 16:36:04 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-launch-configuration") %>>
<a href="/docs/providers/aws/r/launch_configuration.html">aws_launch_configuration</a>
</li>
provider/aws: spot_instance_request This is an iteration on the great work done by @dalehamel in PRs #2095 and #2109. The core team went back and forth on how to best model Spot Instance Requests, requesting and then rejecting a separate-resource implementation in #2109. After more internal discussion, we landed once again on a separate resource to model Spot Instance Requests. Out of respect for @dalehamel's already-significant donated time, with this I'm attempting to pick up the work to take this across the finish line. Important architectural decisions represented here: * Spot Instance Requests are always of type "persistent", to properly match Terraform's declarative model. * The spot_instance_request resource exports several attributes that are expected to be constantly changing as the spot market changes: spot_bid_status, spot_request_state, and instance_id. Creating additional resource dependencies based on these attributes is not recommended, as Terraform diffs will be continually generated to keep up with the live changes. * When a Spot Instance Request is deleted/canceled, an attempt is made to terminate the last-known attached spot instance. Race conditions dictate that this attempt cannot guarantee that the associated spot instance is terminated immediately. Implementation notes: * This version of aws_spot_instance_request borrows a lot of common code from aws_instance. * In order to facilitate borrowing, we introduce `awsInstanceOpts`, an internal representation of instance details that's meant to be shared between resources. The goal here would be to refactor ASG Launch Configurations to use the same struct. * The new aws_spot_instance_request acc. test is passing. * All aws_instance acc. tests remain passing.
2015-06-05 17:12:09 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-lb-cookie-stickiness-policy") %>>
<a href="/docs/providers/aws/r/lb_cookie_stickiness_policy.html">aws_lb_cookie_stickiness_policy</a>
</li>
provider/aws: Add Security Group Rule as a top level resource - document conflict with sg rules and sg in-line rules - for this to work, ingress rules need to be computed
2015-04-20 20:38:21 +02:00
provider/aws: Add docs for aws_placement_group
2015-10-08 21:58:03 +02:00
<li<%= sidebar_current("docs-aws-resource-placement-group") %>>
<a href="/docs/providers/aws/r/placement_group.html">aws_placement_group</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-proxy-protocol-policy") %>>
<a href="/docs/providers/aws/r/proxy_protocol_policy.html">aws_proxy_protocol_policy</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
provider/aws: Document Volume Attachment
2015-05-28 17:33:20 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-spot-instance-request") %>>
<a href="/docs/providers/aws/r/spot_instance_request.html">aws_spot_instance_request</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-volume-attachment") %>>
<a href="/docs/providers/aws/r/volume_attachment.html">aws_volume_attachment</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
</ul>
</li>
aws: Add docs for aws_vpn_connection resources.
2015-05-01 18:23:39 +02:00
Docs: Sort AWS resources alphabetically
2015-05-30 16:36:04 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current(/^docs-aws-resource-ecs/) %>>
<a href="#">ECS Resources</a>
<ul class="nav nav-visible">
Docs: Sort AWS resources alphabetically
2015-05-30 16:36:04 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-ecs-cluster") %>>
<a href="/docs/providers/aws/r/ecs_cluster.html">aws_ecs_cluster</a>
</li>
providers/aws: Implements DHCP Options Set support.
2015-04-28 21:57:05 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-ecs-service") %>>
<a href="/docs/providers/aws/r/ecs_service.html">aws_ecs_service</a>
</li>
aws: Add documentation for VPN connection routes.
2015-05-04 18:21:22 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-ecs-task-definition") %>>
<a href="/docs/providers/aws/r/ecs_task_definition.html">aws_ecs_task_definition</a>
</li>
</ul>
</li>
provider/aws: Add docs for EFS resources
2015-09-16 13:44:41 +02:00
<li<%= sidebar_current(/^docs-aws-resource-efs/) %>>
<a href="#">EFS Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-efs-file-system") %>>
<a href="/docs/providers/aws/r/efs_file_system.html">aws_efs_file_system</a>
</li>
<li<%= sidebar_current("docs-aws-resource-efs-mount-target") %>>
<a href="/docs/providers/aws/r/efs_mount_target.html">aws_efs_mount_target</a>
</li>
</ul>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current(/^docs-aws-resource-elasticache/) %>>
<a href="#">ElastiCache Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-elasticache-cluster") %>>
<a href="/docs/providers/aws/r/elasticache_cluster.html">aws_elasticache_cluster</a>
</li>
<li<%= sidebar_current("docs-aws-resource-elasticache-parameter-group") %>>
<a href="/docs/providers/aws/r/elasticache_parameter_group.html">aws_elasticache_parameter_group</a>
</li>
<li<%= sidebar_current("docs-aws-resource-elasticache-security-group") %>>
<a href="/docs/providers/aws/r/elasticache_security_group.html">aws_elasticache_security_group</a>
</li>
<li<%= sidebar_current("docs-aws-resource-elasticache-subnet-group") %>>
<a href="/docs/providers/aws/r/elasticache_subnet_group.html">aws_elasticache_subnet_group</a>
</li>
</ul>
</li>
provider/aws: Add docs for aws_elasticsearch_domain
2015-10-02 00:13:32 +02:00
<li<%= sidebar_current(/^docs-aws-resource-elasticsearch/) %>>
<a href="#">ElasticSearch Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-elasticsearch-domain") %>>
<a href="/docs/providers/aws/r/elasticsearch_domain.html">aws_elasticsearch_domain</a>
</li>
</ul>
</li>
Adding the the docs for the Glacier Vault resource Updating the glacier docs to include a link to the AWS developer guide
2015-09-16 00:32:54 +02:00
<li<%= sidebar_current(/^docs-aws-resource-glacier/) %>>
<a href="#">Glacier Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-glacier-vault") %>>
<a href="/docs/providers/aws/r/glacier_vault.html">aws_glacier_vault</a>
</li>
</ul>
</li>
provider/aws: Add docs for aws_elasticsearch_domain
2015-10-02 00:13:32 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current(/^docs-aws-resource-iam/) %>>
<a href="#">IAM Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-iam-access-key") %>>
<a href="/docs/providers/aws/r/iam_access_key.html">aws_iam_access_key</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-group") %>>
<a href="/docs/providers/aws/r/iam_group.html">aws_iam_group</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-group-policy") %>>
<a href="/docs/providers/aws/r/iam_group_policy.html">aws_iam_group_policy</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-group-membership") %>>
<a href="/docs/providers/aws/r/iam_group_membership.html">aws_iam_group_membership</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-instance-profile") %>>
<a href="/docs/providers/aws/r/iam_instance_profile.html">aws_iam_instance_profile</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-policy") %>>
<a href="/docs/providers/aws/r/iam_policy.html">aws_iam_policy</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-policy-attachment") %>>
<a href="/docs/providers/aws/r/iam_policy_attachment.html">aws_iam_policy_attachment</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-role") %>>
<a href="/docs/providers/aws/r/iam_role.html">aws_iam_role</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-role-policy") %>>
<a href="/docs/providers/aws/r/iam_role_policy.html">aws_iam_role_policy</a>
</li>
provider/aws: Add docs for aws_iam_saml_provider
2015-09-02 21:01:36 +02:00
<li<%= sidebar_current("docs-aws-resource-iam-saml-provider") %>>
<a href="/docs/providers/aws/r/iam_saml_provider.html">aws_iam_saml_provider</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-iam-server-certificate") %>>
<a href="/docs/providers/aws/r/iam_server_certificate.html">aws_iam_server_certificate</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-user") %>>
<a href="/docs/providers/aws/r/iam_user.html">aws_iam_user</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-user-policy") %>>
<a href="/docs/providers/aws/r/iam_user_policy.html">aws_iam_user_policy</a>
</li>
</ul>
</li>
<li<%= sidebar_current(/^docs-aws-resource-kinesis/) %>>
<a href="#">Kinesis Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-kinesis-stream") %>>
<a href="/docs/providers/aws/r/kinesis_stream.html">aws_kinesis_stream</a>
</li>
</ul>
</li>
Adding the documentation for the Kinesis Firehose Delivery Stream
2015-11-10 17:43:34 +01:00
<li<%= sidebar_current(/^docs-aws-resource-kinesis-firehose/) %>>
<a href="#">Kinesis Firehose Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-kinesis-firehose-delivery-stream") %>>
<a href="/docs/providers/aws/r/kinesis_firehose_delivery_stream.html">aws_kinesis_firehose_delivery_stream</a>
</li>
</ul>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current(/^docs-aws-resource-lambda/) %>>
<a href="#">Lambda Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-lambda-function") %>>
<a href="/docs/providers/aws/r/lambda_function.html">aws_lambda_function</a>
</li>
</ul>
</li>
Prepare for adding OpsWorks resources. Here we add an OpsWorks client instance to the central client bundle and establish a new documentation section, both of which will be fleshed out in subsequent commits that add some OpsWorks resources.
2015-05-11 05:20:17 +02:00
<li<%= sidebar_current(/^docs-aws-resource-opsworks/) %>>
<a href="#">OpsWorks Resources</a>
<ul class="nav nav-visible">
Various AWS OpsWorks layer resource types. A "Layer" is a particular service that forms part of the infrastructure for a set of applications. Some layers are application servers and others are pure infrastructure, like MySQL servers or load balancers. Although the AWS API only has one type called "Layer", it actually has a number of different "soft" types that each have slightly different validation rules and extra properties that are packed into the Attributes map. To make the validation rule differences explicit in Terraform, and to make the Terraform structure more closely resemble the OpsWorks UI than its API, we use a separate resource type per layer type, with the common code factored out into a shared struct type.
2015-06-01 07:07:32 +02:00
<li<%= sidebar_current("docs-aws-resource-opsworks-custom-layer") %>>
<a href="/docs/providers/aws/r/opsworks_custom_layer.html">aws_opsworks_custom_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-ganglia-layer") %>>
<a href="/docs/providers/aws/r/opsworks_ganglia_layer.html">aws_opsworks_ganglia_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-haproxy-layer") %>>
<a href="/docs/providers/aws/r/opsworks_haproxy_layer.html">aws_opsworks_haproxy_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-java-app-layer") %>>
<a href="/docs/providers/aws/r/opsworks_java_app_layer.html">aws_opsworks_java_app_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-memcached-layer") %>>
<a href="/docs/providers/aws/r/opsworks_memcached_layer.html">aws_opsworks_memcached_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-mysql-layer") %>>
<a href="/docs/providers/aws/r/opsworks_mysql_layer.html">aws_opsworks_mysql_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-nodejs-app-layer") %>>
<a href="/docs/providers/aws/r/opsworks_nodejs_app_layer.html">aws_opsworks_nodejs_app_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-php-app-layer") %>>
<a href="/docs/providers/aws/r/opsworks_php_app_layer.html">aws_opsworks_php_app_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-rails-app-layer") %>>
<a href="/docs/providers/aws/r/opsworks_rails_app_layer.html">aws_opsworks_rails_app_layer</a>
</li>
aws_opswork_stack resource type. "Stack" is the root concept in OpsWorks, and acts as a container for a number of different "layers" that each provide some service for an application. A stack isn't very interesting on its own, but it needs to be created before any layers can be created.
2015-05-11 05:21:03 +02:00
<li<%= sidebar_current("docs-aws-resource-opsworks-stack") %>>
<a href="/docs/providers/aws/r/opsworks_stack.html">aws_opsworks_stack</a>
</li>
Various AWS OpsWorks layer resource types. A "Layer" is a particular service that forms part of the infrastructure for a set of applications. Some layers are application servers and others are pure infrastructure, like MySQL servers or load balancers. Although the AWS API only has one type called "Layer", it actually has a number of different "soft" types that each have slightly different validation rules and extra properties that are packed into the Attributes map. To make the validation rule differences explicit in Terraform, and to make the Terraform structure more closely resemble the OpsWorks UI than its API, we use a separate resource type per layer type, with the common code factored out into a shared struct type.
2015-06-01 07:07:32 +02:00
<li<%= sidebar_current("docs-aws-resource-opsworks-static-web-layer") %>>
<a href="/docs/providers/aws/r/opsworks_static_web_layer.html">aws_opsworks_static_web_layer</a>
</li>
Prepare for adding OpsWorks resources. Here we add an OpsWorks client instance to the central client bundle and establish a new documentation section, both of which will be fleshed out in subsequent commits that add some OpsWorks resources.
2015-05-11 05:20:17 +02:00
</ul>
</li>
provider/aws: Docs for RDS Cluster, Cluster Instance
2015-08-04 23:24:55 +02:00
<li<%= sidebar_current(/^docs-aws-resource-(db|rds)/) %>>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<a href="#">RDS Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-db-instance") %>>
<a href="/docs/providers/aws/r/db_instance.html">aws_db_instance</a>
</li>
<li<%= sidebar_current("docs-aws-resource-db-parameter-group") %>>
<a href="/docs/providers/aws/r/db_parameter_group.html">aws_db_parameter_group</a>
</li>
<li<%= sidebar_current("docs-aws-resource-db-security-group") %>>
<a href="/docs/providers/aws/r/db_security_group.html">aws_db_security_group</a>
</li>
<li<%= sidebar_current("docs-aws-resource-db-subnet-group") %>>
<a href="/docs/providers/aws/r/db_subnet_group.html">aws_db_subnet_group</a>
</li>
provider/aws: Docs for RDS Cluster, Cluster Instance
2015-08-04 23:24:55 +02:00
<li<%= sidebar_current("docs-aws-resource-rds-cluster") %>>
<a href="/docs/providers/aws/r/rds_cluster.html">aws_rds_cluster</a>
</li>
<li<%= sidebar_current("docs-aws-resource-rds-cluster-instance") %>>
<a href="/docs/providers/aws/r/rds_cluster_instance.html">aws_rds_cluster_instance</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
</ul>
</li>
<li<%= sidebar_current(/^docs-aws-resource-route53/) %>>
<a href="#">Route53 Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-route53-delegation-set") %>>
<a href="/docs/providers/aws/r/route53_delegation_set.html">aws_route53_delegation_set</a>
</li>
<li<%= sidebar_current("docs-aws-resource-route53-health-check") %>>
<a href="/docs/providers/aws/r/route53_health_check.html">aws_route53_health_check</a>
</li>
<li<%= sidebar_current("docs-aws-resource-route53-record") %>>
<a href="/docs/providers/aws/r/route53_record.html">aws_route53_record</a>
</li>
<li<%= sidebar_current("docs-aws-resource-route53-zone") %>>
<a href="/docs/providers/aws/r/route53_zone.html">aws_route53_zone</a>
</li>
<li<%= sidebar_current("docs-aws-resource-route53-zone-association") %>>
<a href="/docs/providers/aws/r/route53_zone_association.html">aws_route53_zone_association</a>
</li>
Add aws_route resource
2015-06-24 05:44:02 +02:00
<li<%= sidebar_current("docs-aws-resource-route|") %>>
<a href="/docs/providers/aws/r/route.html">aws_route</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
</ul>
</li>
<li<%= sidebar_current(/^docs-aws-resource-s3/) %>>
<a href="#">S3 Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-s3-bucket") %>>
<a href="/docs/providers/aws/r/s3_bucket.html">aws_s3_bucket</a>
</li>
update docs
2015-07-30 22:17:16 +02:00
<li<%= sidebar_current("docs-aws-resource-s3-bucket-object") %>>
<a href="/docs/providers/aws/r/s3_bucket_object.html">aws_s3_bucket_object</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
</ul>
</li>
<li<%= sidebar_current(/^docs-aws-resource-sns/) %>>
<a href="#">SNS Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-sns-topic") %>>
<a href="/docs/providers/aws/r/sns_topic.html">aws_sns_topic</a>
</li>
<li<%= sidebar_current("docs-aws-resource-sns-topic-subscription") %>>
<a href="/docs/providers/aws/r/sns_topic_subscription.html">aws_sns_topic_subscription</a>
</li>
</ul>
</li>
<li<%= sidebar_current(/^docs-aws-resource-sqs/) %>>
<a href="#">SQS Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-sqs-queue") %>>
<a href="/docs/providers/aws/r/sqs_queue.html">aws_sqs_queue</a>
</li>
</ul>
</li>
<li<%= sidebar_current(/^docs-aws-resource-(customer|flow|internet-gateway|key-pair|main-route|network|route-|security-group|subnet|vpc|vpn)/) %>>
<a href="#">VPC Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-customer-gateway") %>>
<a href="/docs/providers/aws/r/customer_gateway.html">aws_customer_gateway</a>
</li>
<li<%= sidebar_current("docs-aws-resource-flow-log") %>>
<a href="/docs/providers/aws/r/flow_log.html">aws_flow_log</a>
</li>
<li<%= sidebar_current("docs-aws-resource-internet-gateway") %>>
<a href="/docs/providers/aws/r/internet_gateway.html">aws_internet_gateway</a>
</li>
<li<%= sidebar_current("docs-aws-resource-key-pair") %>>
<a href="/docs/providers/aws/r/key_pair.html">aws_key_pair</a>
</li>
<li<%= sidebar_current("docs-aws-resource-main-route-table-assoc") %>>
<a href="/docs/providers/aws/r/main_route_table_assoc.html">aws_main_route_table_association</a>
</li>
<li<%= sidebar_current("docs-aws-resource-network-acl") %>>
<a href="/docs/providers/aws/r/network_acl.html">aws_network_acl</a>
</li>
<li<%= sidebar_current("docs-aws-resource-network-interface") %>>
<a href="/docs/providers/aws/r/network_interface.html">aws_network_interface</a>
</li>
<li<%= sidebar_current("docs-aws-resource-route-table|") %>>
<a href="/docs/providers/aws/r/route_table.html">aws_route_table</a>
</li>
<li<%= sidebar_current("docs-aws-resource-route-table-association") %>>
<a href="/docs/providers/aws/r/route_table_association.html">aws_route_table_association</a>
</li>
<li<%= sidebar_current("docs-aws-resource-security-group") %>>
<a href="/docs/providers/aws/r/security_group.html">aws_security_group</a>
</li>
<li<%= sidebar_current("docs-aws-resource-security-group-rule") %>>
<a href="/docs/providers/aws/r/security_group_rule.html">aws_security_group_rule</a>
</li>
<li<%= sidebar_current("docs-aws-resource-subnet") %>>
<a href="/docs/providers/aws/r/subnet.html">aws_subnet</a>
</li>
<li<%= sidebar_current("docs-aws-resource-vpc") %>>
<a href="/docs/providers/aws/r/vpc.html">aws_vpc</a>
</li>
<li<%= sidebar_current("docs-aws-resource-vpc-dhcp-options") %>>
<a href="/docs/providers/aws/r/vpc_dhcp_options.html">aws_vpc_dhcp_options</a>
</li>
<li<%= sidebar_current("docs-aws-resource-vpc-dhcp-options-association") %>>
<a href="/docs/providers/aws/r/vpc_dhcp_options_association.html">aws_vpc_dhcp_options_association</a>
</li>
<li<%= sidebar_current("docs-aws-resource-vpc-endpoint") %>>
<a href="/docs/providers/aws/r/vpc_endpoint.html">aws_vpc_endpoint</a>
</li>
<li<%= sidebar_current("docs-aws-resource-vpc-peering") %>>
<a href="/docs/providers/aws/r/vpc_peering.html">aws_vpc_peering</a>
</li>
<li<%= sidebar_current("docs-aws-resource-vpn-connection") %>>
<a href="/docs/providers/aws/r/vpn_connection.html">aws_vpn_connection</a>
</li>
<li<%= sidebar_current("docs-aws-resource-vpn-connection-route") %>>
<a href="/docs/providers/aws/r/vpn_connection_route.html">aws_vpn_connection_route</a>
</li>
<li<%= sidebar_current("docs-aws-resource-vpn-gateway") %>>
<a href="/docs/providers/aws/r/vpn_gateway.html">aws_vpn_gateway</a>
</li>
</ul>
</li>
</ul>
</div>
<% end %>
<%= yield %>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
<% end %>