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

1044 lines
55 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: Add aws_caller_identity data source This data source provides access during configuration to the ID of the AWS account for the connection to AWS. It is primarily useful for interpolating into policy documents, for example when creating the policy for an ELB or ALB access log bucket. This will need revisiting and further testing once the work for AssumeRole is integrated.
2016-08-15 23:43:24 +02:00
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: availability zone data source This adds a singular data source in addition to the existing plural one. This allows retrieving data about a specific AZ. As a helper for writing reusable modules, the AZ letter (without its usual region name prefix) is exposed so that it can be used in region-agnostic mappings where a different value is used per AZ, such as for subnet numbering schemes.
2016-05-22 19:21:02 +02:00
<li<%= sidebar_current("docs-aws-datasource-availability-zone") %>>
<a href="/docs/providers/aws/d/availability_zone.html">aws_availability_zone</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: Add aws_caller_identity data source This data source provides access during configuration to the ID of the AWS account for the connection to AWS. It is primarily useful for interpolating into policy documents, for example when creating the policy for an ELB or ALB access log bucket. This will need revisiting and further testing once the work for AssumeRole is integrated.
2016-08-15 23:43:24 +02:00
<li<%= sidebar_current("docs-aws-datasource-caller-identity") %>>
<a href="/docs/providers/aws/d/caller_identity.html">aws_caller_identity</a>
</li>
provider/aws: Add cloudformation_stack data source
2016-06-02 11:08:12 +02:00
<li<%= sidebar_current("docs-aws-datasource-cloudformation-stack") %>>
<a href="/docs/providers/aws/d/cloudformation_stack.html">aws_cloudformation_stack</a>
</li>
docs/aws: Fix ordering of data sources (#7970)
2016-08-04 10:40:45 +02:00
<li<%= sidebar_current("docs-aws-datasource-ecs-container-definition") %>>
<a href="/docs/providers/aws/d/ecs_container_definition.html">aws_ecs_container_definition</a>
</li>
aws: Implement naming changes for aws_elb_service_account
2016-08-16 22:05:27 +02:00
<li<%= sidebar_current("docs-aws-datasource-elb-service-account") %>>
<a href="/docs/providers/aws/d/elb_service_account.html">aws_elb_service_account</a>
aws: Add elb_account_id data source
2016-08-16 11:17:53 +02:00
</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>
Added documentation.
2016-08-05 17:12:46 +02:00
<li<%= sidebar_current("docs-aws-datasource-ip_ranges") %>>
<a href="/docs/providers/aws/d/ip_ranges.html">aws_ip_ranges</a>
</li>
provider/aws: aws_region data source The primary purpose of this data source is to ask the question "what is my current region?", but it can also be used to retrieve the endpoint hostname for a particular (possibly non-current) region, should that be useful for some esoteric case.
2016-05-22 19:22:09 +02:00
<li<%= sidebar_current("docs-aws-datasource-redshift-service-account") %>>
<a href="/docs/providers/aws/d/redshift_service_account.html">aws_redshift_service_account</a>
</li>
<li<%= sidebar_current("docs-aws-datasource-region") %>>
<a href="/docs/providers/aws/d/region.html">aws_region</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: aws_subnet data source
2016-05-22 17:23:25 +02:00
<li<%= sidebar_current("docs-aws-datasource-subnet") %>>
<a href="/docs/providers/aws/d/subnet.html">aws_subnet</a>
</li>
provider/aws: aws_vpc data source
2016-05-22 17:25:30 +02:00
<li<%= sidebar_current("docs-aws-datasource-vpc") %>>
<a href="/docs/providers/aws/d/vpc.html">aws_vpc</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
</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>
website: Docs for AWS API Gateway domain name and base path mapping
2016-08-21 23:13:48 +02:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-base-path-mapping") %>>
<a href="/docs/providers/aws/r/api_gateway_base_path_mapping.html">aws_api_gateway_base_path_mapping</a>
</li>
provider/aws: Add API Gateway Client Certificate
2016-09-11 16:14:10 +02:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-client-certificate") %>>
<a href="/docs/providers/aws/r/api_gateway_client_certificate.html">aws_api_gateway_client_certificate</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>
website: Docs for AWS API Gateway domain name and base path mapping
2016-08-21 23:13:48 +02:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-domain-name") %>>
<a href="/docs/providers/aws/r/api_gateway_domain_name.html">aws_api_gateway_domain_name</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>
docs/aws: Add the App Autoscaling Resources to the nav bar in a section of their own
2016-07-26 11:50:17 +02:00
<li<%= sidebar_current(/^docs-aws-resource-appautoscaling/) %>>
<a href="#">App Autoscaling Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-appautoscaling-policy") %>>
<a href="/docs/providers/aws/r/appautoscaling_policy.html">aws_appautoscaling_policy</a>
</li>
<li<%= sidebar_current("docs-aws-resource-appautoscaling-target") %>>
<a href="/docs/providers/aws/r/appautoscaling_target.html">aws_appautoscaling_target</a>
</li>
</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>
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>
provider/aws: `aws_cloudwatch_log_stream` resource This is a requirement for enabling CloudWatch Logging on Kinesis Firehost % make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSCloudWatchLogStream_' ==> Checking that code complies with gofmt requirements... go generate $(go list ./... | grep -v /terraform/vendor/) 2016/09/02 16:19:14 Generated command/internal_plugin_list.go TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSCloudWatchLogStream_ -timeout 120m === RUN TestAccAWSCloudWatchLogStream_basic --- PASS: TestAccAWSCloudWatchLogStream_basic (22.31s) === RUN TestAccAWSCloudWatchLogStream_disappears --- PASS: TestAccAWSCloudWatchLogStream_disappears (21.21s) PASS ok github.com/hashicorp/terraform/builtin/providers/aws 43.538s
2016-09-02 13:29:48 +02:00
<li<%= sidebar_current("docs-aws-resource-cloudwatch-log-stream") %>>
<a href="/docs/providers/aws/r/cloudwatch_log_stream.html">aws_cloudwatch_log_stream</a>
</li>
aws: Sort sidebar items alphabetically (#8223)
2016-08-16 13:37:33 +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>
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>
Added Codecommit Trigger
2016-09-08 10:54:54 +02:00
<li<%= sidebar_current("docs-aws-resource-codecommit-trigger") %>>
<a href="/docs/providers/aws/r/code_commit_trigger.html">aws_codecommit_trigger</a>
</li>
Added the documentation for the CodeCommit repository
2015-10-30 22:38:13 +01:00
</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 `aws_alb` resource This commit adds a resource, acceptance tests and documentation for the new Application Load Balancer (aws_alb). We choose to use the name alb over the package name, elbv2, in order to avoid confusion. This is the first in a series of commits to fully support the new resources necessary for Application Load Balancers.
2016-08-15 23:09:40 +02:00
<li<%= sidebar_current(/^docs-aws-resource-(alb|ami|app|autoscaling|ebs|elb|eip|instance|launch|lb|proxy|spot|volume|placement|key-pair|elb_attachment|load-balancer)/) %>>
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
provider/aws: Add `aws_alb` resource This commit adds a resource, acceptance tests and documentation for the new Application Load Balancer (aws_alb). We choose to use the name alb over the package name, elbv2, in order to avoid confusion. This is the first in a series of commits to fully support the new resources necessary for Application Load Balancers.
2016-08-15 23:09:40 +02:00
<li<%= sidebar_current("docs-aws-resource-alb") %>>
<a href="/docs/providers/aws/r/alb.html">aws_alb</a>
</li>
provider/aws: Add aws_alb_listener resource This commit adds the `aws_alb_listener` resource and associated acceptance tests and documentation.
2016-08-17 19:42:18 +02:00
<li<%= sidebar_current("docs-aws-resource-alb-listener") %>>
<a href="/docs/providers/aws/r/alb_listener.html">aws_alb_listener</a>
</li>
provider/aws: Add aws_alb_listener_rule resource This commit adds the aws_alb_listener_rule resource along with acceptance tests and documentation.
2016-08-19 00:43:11 +02:00
<li<%= sidebar_current("docs-aws-resource-alb-listener-rule") %>>
<a href="/docs/providers/aws/r/alb_listener_rule.html">aws_alb_listener_rule</a>
</li>
provider/aws: Add aws_alb_target_group resource This commit adds a resource, acceptance tests and documentation for the Target Groups for Application Load Balancers. This is the second in a series of commits to fully support the new resources necessary for Application Load Balancers.
2016-08-15 23:10:54 +02:00
<li<%= sidebar_current("docs-aws-resource-alb-target-group") %>>
<a href="/docs/providers/aws/r/alb_target_group.html">aws_alb_target_group</a>
provider/aws: Add aws_alb_listener resource This commit adds the `aws_alb_listener` resource and associated acceptance tests and documentation.
2016-08-17 19:42:18 +02:00
</li>
provider/aws: Add aws_alb_target_group resource This commit adds a resource, acceptance tests and documentation for the Target Groups for Application Load Balancers. This is the second in a series of commits to fully support the new resources necessary for Application Load Balancers.
2016-08-15 23:10:54 +02:00
provider/aws: Add aws_alb_target_group_attachment
2016-08-19 17:12:19 +02:00
<li<%= sidebar_current("docs-aws-resource-alb-target-group-attachment") %>>
<a href="/docs/providers/aws/r/alb_target_group_attachment.html">aws_alb_target_group_attachment</a>
</li>
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>
docs/aws: Adding to the docs side bar
2016-08-05 02:36:10 +02:00
<li<%= sidebar_current("docs-aws-resource-ami-launch-permission") %>>
docs: Fix resource name (#8220)
2016-08-16 11:06:57 +02:00
<a href="/docs/providers/aws/r/ami_launch_permission.html">aws_ami_launch_permission</a>
docs/aws: Adding to the docs side bar
2016-08-05 02:36:10 +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-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
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
aws: Sort sidebar items alphabetically (#8223)
2016-08-16 13:37:33 +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-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
aws: Sort sidebar items alphabetically (#8223)
2016-08-16 13:37:33 +02:00
<li<%= sidebar_current("docs-aws-resource-lb-ssl-negotiation-policy") %>>
<a href="/docs/providers/aws/r/lb_ssl_negotiation_policy.html">aws_lb_ssl_negotiation_policy</a>
</li>
provider/aws: Add the documentation for the new * resources to the ERB layout
2016-08-09 05:43:02 +02:00
<li<%= sidebar_current("docs-aws-resource-load-balancer-backend-server-policy") %>>
<a href="/docs/providers/aws/r/load_balancer_backend_server_policy.html">aws_load_balancer_backend_server_policy</a>
</li>
<li<%= sidebar_current("docs-aws-resource-load-balancer-listener-policy") %>>
<a href="/docs/providers/aws/r/load_balancer_listener_policy.html">aws_load_balancer_listener_policy</a>
</li>
<li<%= sidebar_current("docs-aws-resource-load-balancer-policy") %>>
<a href="/docs/providers/aws/r/load_balancer_policy.html">aws_load_balancer_policy</a>
</li>
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: New resource `aws_spot_datafeed_subscription` Fixes: #4922 ``` % make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSSpotDatafeedSubscription_' ==> Checking that code complies with gofmt requirements... /Users/stacko/Code/go/bin/stringer go generate $(go list ./... | grep -v /terraform/vendor/) 2016/08/24 10:46:23 Generated command/internal_plugin_list.go TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSSpotDatafeedSubscription_ -timeout 120m === RUN TestAccAWSSpotDatafeedSubscription_importBasic --- PASS: TestAccAWSSpotDatafeedSubscription_importBasic (56.31s) === RUN TestAccAWSSpotDatafeedSubscription_basic --- PASS: TestAccAWSSpotDatafeedSubscription_basic (56.77s) === RUN TestAccAWSSpotDatafeedSubscription_disappears --- PASS: TestAccAWSSpotDatafeedSubscription_disappears (56.79s) PASS ok github.com/hashicorp/terraform/builtin/providers/aws 169.893s ```
2016-08-24 11:51:57 +02:00
<li<%= sidebar_current("docs-aws-resource-spot-datafeed-subscription") %>>
<a href="/docs/providers/aws/r/spot_datafeed_subscription.html">aws_spot_datafeed_subscription</a>
</li>
aws: Sort sidebar items alphabetically (#8223)
2016-08-16 13:37:33 +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>
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>
</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
aws: Sort sidebar items alphabetically (#8223)
2016-08-16 13:37:33 +02: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
<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>
provider/aws: Implement the `aws_elasticache_replication_group` resource (#8275)
2016-08-18 20:42:29 +02:00
<li<%= sidebar_current("docs-aws-resource-elasticache-replication-group") %>>
<a href="/docs/providers/aws/r/elasticache_replication_group.html">aws_elasticache_replication_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-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>
re-go-fmt after rebase use us-west-2 region in tests update test with working config provider/aws: Update EMR contribution with passing test, polling for instance in DELETE method remove defaulted role document emr_cluster rename aws_emr -> aws_emr_cluster update docs for name change update delete timeout/polling rename emr taskgroup to emr instance group default instance group count to 0, down from 60 update to ref emr_cluster, emr_instance_group more cleanups for instance groups; need to read and update add read, delete method for instance groups refactor the read method to seperate out the fetching of the specific group more refactoring for finding instance groups update emr instance group docs err check on reading HTTP. Dont' return the error, just log it refactor the create method to catch optionals additional cleanups, added a read method update test to be non-master-only wrap up the READ method for clusters poll for instance group to be running after a modification patch up a possible deref provider/aws: EMR cleanups fix test naming remove outdated docs randomize emr_profile names
2016-09-22 21:59:13 +02:00
<li<%= sidebar_current(/^docs-aws-resource-emr/) %>>
<a href="#">Elastic Map Reduce Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-emr-cluster") %>>
<a href="/docs/providers/aws/r/emr_cluster.html">aws_emr_cluster</a>
</li>
<li<%= sidebar_current("docs-aws-resource-emr-instance-group") %>>
<a href="/docs/providers/aws/r/emr_instance_group.html">aws_emr_instance_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>
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>
aws: Sort sidebar items alphabetically (#8223)
2016-08-16 13:37:33 +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>
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-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-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>
provider/aws: Docs for aws_iam_user_login_profile
2016-10-25 19:08:14 +02:00
<li<%= sidebar_current("docs-aws-resource-iam-user-login-profile") %>>
<a href="/docs/providers/aws/r/iam_user_login_profile.html">aws_iam_user_login_profile</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-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-alias") %>>
<a href="/docs/providers/aws/r/kms_alias.html">aws_kms_alias</a>
</li>
aws: Sort sidebar items alphabetically (#8223)
2016-08-16 13:37:33 +02:00
<li<%= sidebar_current("docs-aws-resource-kms-key") %>>
<a href="/docs/providers/aws/r/kms_key.html">aws_kms_key</a>
</li>
Added docs for kms
2015-10-26 15:47:35 +01:00
</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>
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>
aws: Sort sidebar items alphabetically (#8223)
2016-08-16 13:37:33 +02:00
<li<%= sidebar_current("docs-aws-resource-lambda-function") %>>
<a href="/docs/providers/aws/r/lambda_function.html">aws_lambda_function</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">
Sort links in sidebar
2016-08-09 17:14:49 +02:00
<li<%= sidebar_current("docs-aws-resource-opsworks-application") %>>
<a href="/docs/providers/aws/r/opsworks_application.html">aws_opsworks_application</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-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>
Add links to sidebar
2016-08-09 17:15:56 +02:00
<li<%= sidebar_current("docs-aws-resource-opsworks-permission") %>>
<a href="/docs/providers/aws/r/opsworks_permission.html">aws_opsworks_permission</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-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>
Add links to sidebar
2016-08-09 17:15:56 +02:00
<li<%= sidebar_current("docs-aws-resource-opsworks-user-profile") %>>
<a href="/docs/providers/aws/r/opsworks_user_profile.html">aws_opsworks_user_profile</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">
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>
aws: Sort sidebar items alphabetically (#8223)
2016-08-16 13:37:33 +02:00
<li<%= sidebar_current("docs-aws-resource-db-instance") %>>
<a href="/docs/providers/aws/r/db_instance.html">aws_db_instance</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>
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>
aws: Sort sidebar items alphabetically (#8223)
2016-08-16 13:37:33 +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: Add aws_s3_bucket_policy resource This commit adds a new "attachment" style resource for setting the policy of an AWS S3 bucket. This is desirable such that the ARN of the bucket can be referenced in an IAM Policy Document. In addition, we now suppress diffs on the (now-computed) policy in the S3 bucket for structurally equivalent policies, which prevents flapping because of whitespace and map ordering changes made by the S3 endpoint.
2016-09-02 00:34:45 +02:00
<li<%= sidebar_current("docs-aws-resource-s3-bucket-policy") %>>
<a href="/docs/providers/aws/r/s3_bucket_policy.html">aws_s3_bucket_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>
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>
provider/aws: Add aws_sns_topic_policy
2016-09-04 09:30:10 +02:00
<li<%= sidebar_current("docs-aws-resource-sns-topic-policy") %>>
<a href="/docs/providers/aws/r/sns_topic_policy.html">aws_sns_topic_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-sns-topic-subscription") %>>
<a href="/docs/providers/aws/r/sns_topic_subscription.html">aws_sns_topic_subscription</a>
</li>
</ul>
</li>
aws/docs: Add missing ssm link to the sidebar (#8476)
2016-08-25 18:46:52 +02:00
<li<%= sidebar_current(/^docs-aws-resource-ssm/) %>>
<a href="#">SSM Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-ssm-document") %>>
<a href="/docs/providers/aws/r/ssm_document.html">aws_ssm_document</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-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>
provider/aws: Add aws_sqs_queue_policy
2016-09-05 08:45:04 +02:00
<li<%= sidebar_current("docs-aws-resource-sqs-queue-policy") %>>
<a href="/docs/providers/aws/r/sqs_queue_policy.html">aws_sqs_queue_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: 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>
aws: Sort sidebar items alphabetically (#8223)
2016-08-16 13:37:33 +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>
provider/aws: Add aws_default_route_table resource (#8323) * provider/aws: Add docs for Default Route Table * add new default_route_table_id attribute, test to VPC * stub * add warning to docs * rough implementation * first test * update test, add swap test * fix typo
2016-08-25 23:02:44 +02:00
<li<%= sidebar_current("docs-aws-resource-default-route-table") %>>
<a href="/docs/providers/aws/r/default_route_table.html">aws_default_route_table</a>
</li>
provider/aws: Add Default Security Group Resource (#8861) * Docs for default security group * overrides of default behavior * add special disclaimer * update to support classic environments
2016-09-15 20:59:20 +02:00
<li<%= sidebar_current("docs-aws-resource-default-security-group") %>>
<a href="/docs/providers/aws/r/default_security_group.html">aws_default_security_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-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>
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>
Add aws_vpn_gateway_attachment resource. (#7870) This commit adds VPN Gateway attachment resource, and also an initial tests and documentation stubs. Signed-off-by: Krzysztof Wilczynski <krzysztof.wilczynski@linux.com>
2016-08-07 01:29:51 +02:00
<li<%= sidebar_current("docs-aws-resource-vpn-gateway-attachment") %>>
<a href="/docs/providers/aws/r/vpn_gateway_attachment.html">aws_vpn_gateway_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
</ul>
</li>
</ul>
</div>
<% end %>
<%= yield %>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
<% end %>