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

876 lines
45 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
Update aws.erb fix missing `>`
2016-05-25 18:48:40 +02:00
<li<%= sidebar_current(/^docs-aws-datasource/) %>>
provider/aws: Add aws_availability_zones source This commit adds a data source with a single list, `instance` for the schema which gets populated with the availability zones to which an account has access.
2016-05-14 20:18:51 +02:00
<a href="#">Data Sources</a>
<ul class="nav nav-visible">
provider/aws: New data source: aws_ami This data source allows one to look up the most recent AMI for a specific set of parameters, much like aws ec2 describe-images in the AWS CLI. Basically a refresh of hashicorp/terraform#4396, in data source form.
2015-12-19 00:52:42 +01:00
<li<%= sidebar_current("docs-aws-datasource-ami") %>>
<a href="/docs/providers/aws/d/ami.html">aws_ami</a>
</li>
provider/aws: Add aws_availability_zones source This commit adds a data source with a single list, `instance` for the schema which gets populated with the availability zones to which an account has access.
2016-05-14 20:18:51 +02:00
<li<%= sidebar_current("docs-aws-datasource-availability-zones") %>>
<a href="/docs/providers/aws/d/availability_zones.html">aws_availability_zones</a>
</li>
provider/aws: aws_iam_policy_document data source This brings over the work done by @apparentlymart and @radeksimko in PR #3124, and converts it into a data source for the AWS provider: This commit adds a helper to construct IAM policy documents using familiar Terraform concepts. It makes Terraform-style interpolations easier and resolves the syntax conflict between Terraform interpolations and IAM policy variables by changing the latter to use &{...} for its interpolations. Its use is completely optional and users are free to go on using literal heredocs, file interpolations or whatever else; this just adds another option that fits more naturally into a Terraform config.
2016-05-25 03:50:35 +02:00
<li<%= sidebar_current("docs-aws-datasource-iam-policy-document") %>>
<a href="/docs/providers/aws/d/iam_policy_document.html">aws_iam_policy_document</a>
</li>
provider/aws: aws_s3_object -> aws_s3_bucket_object (docs + filename) (#6979) * aws/docs: Fix s3_bucket_object DS documentation * provider/aws: aws_s3_object -> aws_s3_bucket_object
2016-06-02 13:13:39 +02:00
<li<%= sidebar_current("docs-aws-datasource-s3-bucket-object") %>>
<a href="/docs/providers/aws/d/s3_bucket_object.html">aws_s3_bucket_object</a>
provider/aws: Add s3_bucket_object data source
2016-05-30 17:42:29 +02:00
</li>
provider/aws: Add aws_availability_zones source This commit adds a data source with a single list, `instance` for the schema which gets populated with the availability zones to which an account has access.
2016-05-14 20:18:51 +02:00
</ul>
</li>
Add aws_api_gateway_rest_api resource
2016-03-05 23:13:38 +01:00
<li<%= sidebar_current(/^docs-aws-resource-api-gateway/) %>>
Fix typo (APIGateway -> API Gateway)
2016-03-06 10:24:17 +01:00
<a href="#">API Gateway Resources</a>
Add aws_api_gateway_rest_api resource
2016-03-05 23:13:38 +01:00
<ul class="nav nav-visible">
provider/aws: Add support for api_gateway_account (#6321)
2016-04-27 14:08:59 +02:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-account") %>>
<a href="/docs/providers/aws/r/api_gateway_account.html">aws_api_gateway_account</a>
</li>
provider/aws: Sort API Gateway resources alphabetically
2016-03-06 10:22:27 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-api-key") %>>
<a href="/docs/providers/aws/r/api_gateway_api_key.html">aws_api_gateway_api_key</a>
Add aws_api_gateway_rest_api resource
2016-03-05 23:13:38 +01:00
</li>
provider/aws: Add support for api_gateway_authorizer (#6320)
2016-04-25 13:22:37 +02:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-authorizer") %>>
<a href="/docs/providers/aws/r/api_gateway_authorizer.html">aws_api_gateway_authorizer</a>
</li>
Add aws_api_gateway_deployment resource
2016-03-05 23:19:25 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-deployment") %>>
<a href="/docs/providers/aws/r/api_gateway_deployment.html">aws_api_gateway_deployment</a>
</li>
provider/aws: Sort API Gateway resources alphabetically
2016-03-06 10:22:27 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-integration") %>>
<a href="/docs/providers/aws/r/api_gateway_integration.html">aws_api_gateway_integration</a>
Add aws_api_gateway_model resource
2016-03-05 23:17:55 +01:00
</li>
provider/aws: Sort API Gateway resources alphabetically
2016-03-06 10:22:27 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-integration-response") %>>
<a href="/docs/providers/aws/r/api_gateway_integration_response.html">aws_api_gateway_integration_response</a>
Add aws_api_gateway_resource resource
2016-03-05 23:14:35 +01:00
</li>
Add aws_api_gateway_method resource
2016-03-05 23:15:22 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-method") %>>
<a href="/docs/providers/aws/r/api_gateway_method.html">aws_api_gateway_method</a>
</li>
Add aws_api_gateway_method_response resource
2016-03-05 23:16:16 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-method-response") %>>
<a href="/docs/providers/aws/r/api_gateway_method_response.html">aws_api_gateway_method_response</a>
</li>
provider/aws: Sort API Gateway resources alphabetically
2016-03-06 10:22:27 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-model") %>>
<a href="/docs/providers/aws/r/api_gateway_model.html">aws_api_gateway_model</a>
Add aws_api_gateway_integration resource
2016-03-05 23:16:52 +01:00
</li>
provider/aws: Sort API Gateway resources alphabetically
2016-03-06 10:22:27 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-resource") %>>
<a href="/docs/providers/aws/r/api_gateway_resource.html">aws_api_gateway_resource</a>
</li>
<li<%= sidebar_current("docs-aws-resource-api-gateway-rest-api") %>>
<a href="/docs/providers/aws/r/api_gateway_rest_api.html">aws_api_gateway_rest_api</a>
Add aws_api_gateawy_integration_response resource
2016-03-05 23:17:21 +01:00
</li>
Add aws_api_gateway_rest_api resource
2016-03-05 23:13:38 +01:00
</ul>
</li>
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
CloudFront distribution and origin access identity support (#5221) * CloudFront implementation v3 * Update tests * Refactor - new resource: aws_cloudfront_distribution * Includes a complete re-write of the old aws_cloudfront_web_distribution resource to bring it to feature parity with API and CloudFormation. * Also includes the aws_cloudfront_origin_access_identity resource to generate origin access identities for use with S3.
2016-04-14 21:55:11 +02:00
<li<%= sidebar_current(/^docs-aws-resource-cloudfront/) %>>
<a href="#">CloudFront Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-cloudfront-distribution") %>>
<a href="/docs/providers/aws/r/cloudfront_distribution.html">aws_cloudfront_distribution</a>
</li>
<li<%= sidebar_current("docs-aws-resource-cloudfront-origin-access-identity") %>>
<a href="/docs/providers/aws/r/cloudfront_origin_access_identity.html">aws_cloudfront_origin_access_identity</a>
</li>
</ul>
</li>
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">
provider/aws: Document CloudWatch Events
2016-02-05 00:19:30 +01:00
<li<%= sidebar_current("docs-aws-resource-cloudwatch-event-rule") %>>
<a href="/docs/providers/aws/r/cloudwatch_event_rule.html">aws_cloudwatch_event_rule</a>
</li>
<li<%= sidebar_current("docs-aws-resource-cloudwatch-event-target") %>>
<a href="/docs/providers/aws/r/cloudwatch_event_target.html">aws_cloudwatch_event_target</a>
</li>
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>
Add cloudwatch_logs_subscription_filter provider (#5996)
2016-04-20 21:05:21 +02:00
<li<%= sidebar_current("docs-aws-resource-cloudwatch-log-subscription-filter") %>>
<a href="/docs/providers/aws/r/cloudwatch_log_subscription_filter.html">aws_cloudwatch_log_subscription_filter</a>
</li>
provider/aws: Add docs for CloudWatch Log Metric Filter
2016-03-02 13:20:57 +01:00
<li<%= sidebar_current("docs-aws-resource-cloudwatch-log-metric-filter") %>>
<a href="/docs/providers/aws/r/cloudwatch_log_metric_filter.html">aws_cloudwatch_log_metric_filter</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>
docs/aws: Whitespaces removed
2015-12-23 16:19:28 +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
</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
add sidebar link for elb_attachment
2016-06-07 17:44:37 +02:00
<li<%= sidebar_current(/^docs-aws-resource-(ami|app|autoscaling|ebs|elb|eip|instance|launch|lb|proxy|spot|volume|placement|key-pair|elb_attachment)/) %>>
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
Adding a resource for aws_autoscaling_schedule
2015-12-11 19:13:52 +01:00
<li<%= sidebar_current("docs-aws-resource-autoscaling-schedule") %>>
<a href="/docs/providers/aws/r/autoscaling_schedule.html">aws_autoscaling_schedule</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-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
provider/aws: Change `aws_elastic_ip_association` to have computed parameters (#6552) * New top level AWS resource aws_eip_association * Add documentation for aws_eip_association * Add tests for aws_eip_association * provider/aws: Change `aws_elastic_ip_association` to have computed parameters The AWS API was send ing more parameters than we had set. Therefore, Terraform was showing constant changes when plans were being formed
2016-05-09 19:40:45 +02:00
<li<%= sidebar_current("docs-aws-resource-eip-association") %>>
<a href="/docs/providers/aws/r/eip_association.html">aws_eip_association</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-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
add sidebar link for elb_attachment
2016-06-07 17:44:37 +02:00
<li<%= sidebar_current("docs-aws-resource-elb-attachment") %>>
docs/aws: Fix wrong resource name in sidebar (#7606)
2016-07-12 17:23:35 +02:00
<a href="/docs/providers/aws/r/elb_attachment.html">aws_elb_attachment</a>
add sidebar link for elb_attachment
2016-06-07 17:44:37 +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-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
website: Sort aws_key_pair in the sidebar
2016-02-18 15:22:14 +01:00
<li<%= sidebar_current("docs-aws-resource-key-pair") %>>
<a href="/docs/providers/aws/r/key_pair.html">aws_key_pair</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-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
Add an AWS Spot fleet resource
2016-06-22 02:16:02 +02:00
<li<%= sidebar_current("docs-aws-resource-spot-fleet-request") %>>
<a href="/docs/providers/aws/r/spot_fleet_request.html">aws_spot_fleet_request</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-volume-attachment") %>>
<a href="/docs/providers/aws/r/volume_attachment.html">aws_volume_attachment</a>
</li>
</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
docs/aws: Fix highlighting of ECR in sidebar
2015-12-23 16:21:22 +01:00
<li<%= sidebar_current(/^docs-aws-resource-(ecs|ecr)/) %>>
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="#">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>
provider/aws: mention us-east-1 in ECR docs and tests ECR is only available in us-east-1 for now. Also added missing sidebar links for ECR resources. /cc @nextrevision
2015-12-22 22:59:17 +01:00
<li<%= sidebar_current("docs-aws-resource-ecr-repository") %>>
<a href="/docs/providers/aws/r/ecr_repository.html">aws_ecr_repository</a>
</li>
<li<%= sidebar_current("docs-aws-resource-ecr-repository-policy") %>>
<a href="/docs/providers/aws/r/ecr_repository_policy.html">aws_ecr_repository_policy</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>
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>
docs: Make a separate Elastic Beanstalk section in sidebar
2016-03-08 10:52:39 +01:00
<li<%= sidebar_current(/^docs-aws-resource-elastic-beanstalk/) %>>
<a href="#">Elastic Beanstalk Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-elastic-beanstalk-application") %>>
<a href="/docs/providers/aws/r/elastic_beanstalk_application.html">aws_elastic_beanstalk_application</a>
</li>
<li<%= sidebar_current("docs-aws-resource-elastic-beanstalk-configuration-template") %>>
<a href="/docs/providers/aws/r/elastic_beanstalk_configuration_template.html">aws_elastic_beanstalk_configuration_template</a>
</li>
<li<%= sidebar_current("docs-aws-resource-elastic-beanstalk-environment") %>>
<a href="/docs/providers/aws/r/elastic_beanstalk_environment.html">aws_elastic_beanstalk_environment</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>
Add Elastic Transcoder docs
2016-06-07 22:06:20 +02:00
<li<%= sidebar_current(/^docs-aws-resource-elastic-transcoder/) %>>
<a href="#">Elastic Transcoder Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-elastic-transcoder-pipeline") %>>
aws/docs: Fix Elastic Transcoder docs
2016-07-09 11:53:54 +02:00
<a href="/docs/providers/aws/r/elastic_transcoder_pipeline.html">aws_elastictranscoder_pipeline</a>
Add Elastic Transcoder docs
2016-06-07 22:06:20 +02:00
</li>
<li<%= sidebar_current("docs-aws-resource-elastic-transcoder-preset") %>>
aws/docs: Fix Elastic Transcoder docs
2016-07-09 11:53:54 +02:00
<a href="/docs/providers/aws/r/elastic_transcoder_preset.html">aws_elastictranscoder_preset</a>
Add Elastic Transcoder docs
2016-06-07 22:06:20 +02:00
</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>
provider/aws: Add docs for AWS Account Password Policy resource
2016-02-06 12:41:52 +01:00
<li<%= sidebar_current("docs-aws-resource-iam-account-password-policy") %>>
<a href="/docs/providers/aws/r/iam_account_password_policy.html">aws_iam_account_password_policy</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-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>
provider/aws: Add per user, role and group policy attachment (supersedes #5816) (#6858) * Add per user, role and group policy attachment * Add docs for new IAM policy attachment resources. * Make policy attachment resources manage only 1 entity<->policy attachment * provider/aws: Tidy up IAM Group/User/Role attachments
2016-05-25 18:03:43 +02:00
<li<%= sidebar_current("docs-aws-resource-iam-group-policy-attachment") %>>
<a href="/docs/providers/aws/r/iam_group_policy_attachment.html">aws_iam_group_policy_attachment</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-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>
provider/aws: aws_iam_policy_document data source This brings over the work done by @apparentlymart and @radeksimko in PR #3124, and converts it into a data source for the AWS provider: This commit adds a helper to construct IAM policy documents using familiar Terraform concepts. It makes Terraform-style interpolations easier and resolves the syntax conflict between Terraform interpolations and IAM policy variables by changing the latter to use &{...} for its interpolations. Its use is completely optional and users are free to go on using literal heredocs, file interpolations or whatever else; this just adds another option that fits more naturally into a Terraform config.
2016-05-25 03:50:35 +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-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 per user, role and group policy attachment (supersedes #5816) (#6858) * Add per user, role and group policy attachment * Add docs for new IAM policy attachment resources. * Make policy attachment resources manage only 1 entity<->policy attachment * provider/aws: Tidy up IAM Group/User/Role attachments
2016-05-25 18:03:43 +02:00
<li<%= sidebar_current("docs-aws-resource-iam-role-policy-attachment") %>>
<a href="/docs/providers/aws/r/iam_role_policy_attachment.html">aws_iam_role_policy_attachment</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>
provider/aws: Add per user, role and group policy attachment (supersedes #5816) (#6858) * Add per user, role and group policy attachment * Add docs for new IAM policy attachment resources. * Make policy attachment resources manage only 1 entity<->policy attachment * provider/aws: Tidy up IAM Group/User/Role attachments
2016-05-25 18:03:43 +02:00
<li<%= sidebar_current("docs-aws-resource-iam-user-policy-attachment") %>>
<a href="/docs/providers/aws/r/iam_user_policy_attachment.html">aws_iam_user_policy_attachment</a>
</li>
provider/aws: Add documentation for `aws_iam_user_ssh_key` resource
2016-03-22 02:19:39 +01:00
<li<%= sidebar_current("docs-aws-resource-iam-user-ssh-key") %>>
<a href="/docs/providers/aws/r/iam_user_ssh_key.html">aws_iam_user_ssh_key</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-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>
Added docs for kms
2015-10-26 15:47:35 +01:00
<li<%= sidebar_current(/^docs-aws-resource-kms/) %>>
<a href="#">KMS Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-kms-key") %>>
<a href="/docs/providers/aws/r/kms_key.html">aws_kms_key</a>
</li>
<li<%= sidebar_current("docs-aws-resource-kms-alias") %>>
<a href="/docs/providers/aws/r/kms_alias.html">aws_kms_alias</a>
</li>
</ul>
</li>
Add missing documentation link for #4093
2015-12-01 14:47:12 +01:00
<li<%= sidebar_current(/^docs-aws-resource-lambda/) %>>
<a href="#">Lambda Resources</a>
<ul class="nav nav-visible">
docs: Add missing link to aws_lambda_alias
2016-01-25 13:46:32 +01:00
<li<%= sidebar_current("docs-aws-resource-lambda-alias") %>>
<a href="/docs/providers/aws/r/lambda_alias.html">aws_lambda_alias</a>
</li>
Add missing documentation link for #4093
2015-12-01 14:47:12 +01:00
<li<%= sidebar_current("docs-aws-resource-lambda-function") %>>
<a href="/docs/providers/aws/r/lambda_function.html">aws_lambda_function</a>
</li>
website: Fix missing sidebar_current
2016-03-06 15:51:25 +01:00
<li<%= sidebar_current("docs-aws-resource-lambda-event-source-mapping") %>>
Add missing documentation link for #4093
2015-12-01 14:47:12 +01:00
<a href="/docs/providers/aws/r/lambda_event_source_mapping.html">aws_lambda_event_source_mapping</a>
</li>
provider/aws: Add docs for aws_lambda_permission
2016-01-25 15:20:07 +01:00
<li<%= sidebar_current("docs-aws-resource-lambda-permission") %>>
<a href="/docs/providers/aws/r/lambda_permission.html">aws_lambda_permission</a>
</li>
Add missing documentation link for #4093
2015-12-01 14:47:12 +01:00
</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
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>
Add support for Opsworks Instances New resource checklist - [x] Acceptance testing - [x] Documentation - [x] Well-formed code
2015-12-12 00:35:22 +01:00
<li<%= sidebar_current("docs-aws-resource-opsworks-instance") %>>
<a href="/docs/providers/aws/r/opsworks_instance.html">aws_opsworks_instance</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-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>
Opsworks Application support
2015-12-22 17:45:27 +01:00
<li<%= sidebar_current("docs-aws-resource-opsworks-application") %>>
<a href="/docs/providers/aws/r/opsworks_application.html">aws_opsworks_application</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>
Added RDS event subscriptions (#6367)
2016-05-05 12:14:25 +02:00
<li<%= sidebar_current("docs-aws-resource-db-event-subscription") %>>
<a href="/docs/providers/aws/r/db_event_subscription.html">aws_db_event_subscription</a>
</li>
Scaffold the AWS DB Option Group resource Change the AWS DB Instance to now include the DB Option Group param. Adds a test to prove that it works Add acceptance tests for the AWS DB Option Group work. This ensures that Options can be added and updated Documentation for the AWS DB Option resource
2015-12-21 10:15:52 +01:00
<li<%= sidebar_current("docs-aws-resource-db-option-group") %>>
<a href="/docs/providers/aws/r/db_option_group.html">aws_db_option_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-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>
add resource aws_rds_cluster_parameter_group
2016-02-23 11:52:07 +01:00
<li<%= sidebar_current("docs-aws-resource-rds-cluster-parameter-group") %>>
<a href="/docs/providers/aws/r/rds_cluster_parameter_group.html">aws_rds_cluster_parameter_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
</ul>
</li>
Adding the documentation for the Redshift security groups Creation of the schema, CRUD and acceptance tests for Redshift Parameter Group
2015-11-12 00:37:56 +01:00
<li<%= sidebar_current(/^docs-aws-resource-redshift/) %>>
<a href="#">Redshift Resources</a>
<ul class="nav nav-visible">
Adding the documentation for the AWS Redshift Subnet Group resource also removed the notion of tags from the redshift security group and parameter group documentation until that has been implemented Redshift Cluster CRUD and acceptance tests Removing the Acceptance test for the Cluster Updates. You cannot delete a cluster immediately after performing an operation on it. We would need to add a lot of retry logic to the system to get this test to work Adding some schema validation for RedShift cluster Adding the last of the pieces of a first draft of the Redshift work - this is the documentation
2015-11-12 10:45:22 +01:00
<li<%= sidebar_current("docs-aws-resource-redshift-cluster") %>>
<a href="/docs/providers/aws/r/redshift_cluster.html">aws_redshift_cluster</a>
</li>
Adding the documentation for the Redshift Parameter Groups Changed the aws_redshift_security_group and aws_redshift_parameter_group to remove the tags from the schema. Tags are a little bit more complicated than originally though - I will revisit this later Then added the schema, CRUD functionality and basic acceptance tests for aws_redshift_subnet_group Adding an acceptance test for the Update of subnet_ids in AWS Redshift Subnet Group
2015-11-12 02:10:57 +01:00
<li<%= sidebar_current("docs-aws-resource-redshift-parameter-group") %>>
<a href="/docs/providers/aws/r/redshift_parameter_group.html">aws_redshift_parameter_group</a>
</li>
Adding the documentation for the Redshift security groups Creation of the schema, CRUD and acceptance tests for Redshift Parameter Group
2015-11-12 00:37:56 +01:00
<li<%= sidebar_current("docs-aws-resource-redshift-security-group") %>>
<a href="/docs/providers/aws/r/redshift_security_group.html">aws_redshift_security_group</a>
</li>
Adding the documentation for the AWS Redshift Subnet Group resource also removed the notion of tags from the redshift security group and parameter group documentation until that has been implemented Redshift Cluster CRUD and acceptance tests Removing the Acceptance test for the Cluster Updates. You cannot delete a cluster immediately after performing an operation on it. We would need to add a lot of retry logic to the system to get this test to work Adding some schema validation for RedShift cluster Adding the last of the pieces of a first draft of the Redshift work - this is the documentation
2015-11-12 10:45:22 +01:00
<li<%= sidebar_current("docs-aws-resource-redshift-subnet-group") %>>
<a href="/docs/providers/aws/r/redshift_subnet_group.html">aws_redshift_subnet_group</a>
</li>
Adding the documentation for the Redshift security groups Creation of the schema, CRUD and acceptance tests for Redshift Parameter Group
2015-11-12 00:37:56 +01:00
</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-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>
docs/aws: Whitespaces removed
2015-12-23 16:19:28 +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
</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>
provider/aws: Support S3 bucket notification * Implement aws_s3_bucket_notification resource
2016-04-05 04:23:06 +02:00
<li<%= sidebar_current("docs-aws-resource-s3-bucket-notification") %>>
<a href="/docs/providers/aws/r/s3_bucket_notification.html">aws_s3_bucket_notification</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>
Add SES resource (#5387) * Add SES resource * Detect ReceiptRule deletion outside of Terraform * Handle order of rule actions * Add position field to docs * Fix hashes, add log messages, and other small cleanup * Fix rebase issue * Fix formatting
2016-06-26 23:07:14 +02:00
<li<%= sidebar_current(/^docs-aws-resource-ses/) %>>
<a href="#">SES Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-ses-active-receipt-rule-set") %>>
<a href="/docs/providers/aws/r/ses_active_receipt_rule_set.html">aws_ses_active_receipt_rule_set</a>
</li>
<li<%= sidebar_current("docs-aws-resource-ses-receipt-filter") %>>
<a href="/docs/providers/aws/r/ses_receipt_filter.html">aws_ses_receipt_filter</a>
</li>
aws/docs: Make item ordering in sidebar alphabetical (#7358)
2016-06-27 13:36:32 +02:00
<li<%= sidebar_current("docs-aws-resource-ses-receipt-rule") %>>
<a href="/docs/providers/aws/r/ses_receipt_rule.html">aws_ses_receipt_rule</a>
</li>
Add SES resource (#5387) * Add SES resource * Detect ReceiptRule deletion outside of Terraform * Handle order of rule actions * Add position field to docs * Fix hashes, add log messages, and other small cleanup * Fix rebase issue * Fix formatting
2016-06-26 23:07:14 +02:00
<li<%= sidebar_current("docs-aws-resource-ses-receipt-rule-set") %>>
<a href="/docs/providers/aws/r/ses_receipt_rule_set.html">aws_ses_receipt_rule_set</a>
</li>
</ul>
</li>
SimpleDB domain resource (#7600)
2016-07-12 13:55:58 +02:00
<li<%= sidebar_current(/^docs-aws-resource-simpledb/) %>>
<a href="#">SimpleDB Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-simpledb-domain") %>>
<a href="/docs/providers/aws/r/simpledb_domain.html">aws_simpledb_domain</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-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>
provider/aws: Default Network ACL resource (#6165) * provider/aws: Default Network ACL resource Provides a resource to manage the default AWS Network ACL. VPC Only. * Remove subnet_id update, mark as computed value. Remove extra tag update * refactor default rule number to be a constant * refactor revokeRulesForType to be revokeAllNetworkACLEntries Refactor method to delete all network ACL entries, regardless of type. The previous implementation was under the assumption that we may only eliminate some rule types and possibly not others, so the split was necessary. We're now removing them all, so the logic isn't necessary Several doc and test cleanups are here as well * smite subnet_id, improve docs
2016-04-18 18:02:00 +02:00
<li<%= sidebar_current(/^docs-aws-resource-(default|customer|flow|internet-gateway|main-route|network|route-|security-group|subnet|vpc|vpn)/) %>>
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="#">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-main-route-table-assoc") %>>
<a href="/docs/providers/aws/r/main_route_table_assoc.html">aws_main_route_table_association</a>
</li>
provider/aws: Add aws_nat_gateway Resource
2015-12-18 08:20:13 +01:00
<li<%= sidebar_current("docs-aws-resource-nat-gateway") %>>
<a href="/docs/providers/aws/r/nat_gateway.html">aws_nat_gateway</a>
</li>
provider/aws: Default Network ACL resource (#6165) * provider/aws: Default Network ACL resource Provides a resource to manage the default AWS Network ACL. VPC Only. * Remove subnet_id update, mark as computed value. Remove extra tag update * refactor default rule number to be a constant * refactor revokeRulesForType to be revokeAllNetworkACLEntries Refactor method to delete all network ACL entries, regardless of type. The previous implementation was under the assumption that we may only eliminate some rule types and possibly not others, so the split was necessary. We're now removing them all, so the logic isn't necessary Several doc and test cleanups are here as well * smite subnet_id, improve docs
2016-04-18 18:02:00 +02:00
<li<%= sidebar_current("docs-aws-resource-default-network-acl") %>>
<a href="/docs/providers/aws/r/default_network_acl.html">aws_default_network_acl</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-network-acl") %>>
<a href="/docs/providers/aws/r/network_acl.html">aws_network_acl</a>
</li>
Adds documentation for the AWS Network ACL Rule resource
2015-12-18 18:21:11 +01:00
<li<%= sidebar_current("docs-aws-resource-network-acl-rule") %>>
<a href="/docs/providers/aws/r/network_acl_rule.html">aws_network_acl_rule</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-network-interface") %>>
<a href="/docs/providers/aws/r/network_interface.html">aws_network_interface</a>
</li>
Changing aws_route from Route53 layout to VPC layout
2015-11-29 15:49:45 +01: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
<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") %>>
website: name vpc_peering_connection in docs properly
2016-04-20 21:13:30 +02:00
<a href="/docs/providers/aws/r/vpc_peering.html">aws_vpc_peering_connection</a>
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>
<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 %>