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

710 lines
36 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
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: 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>
Add aws_api_gateway_deployment resource
2016-03-05 23:19:25 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-deployment") %>>
<a href="/docs/providers/aws/r/api_gateway_deployment.html">aws_api_gateway_deployment</a>
</li>
provider/aws: Sort API Gateway resources alphabetically
2016-03-06 10:22:27 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-integration") %>>
<a href="/docs/providers/aws/r/api_gateway_integration.html">aws_api_gateway_integration</a>
Add aws_api_gateway_model resource
2016-03-05 23:17:55 +01:00
</li>
provider/aws: Sort API Gateway resources alphabetically
2016-03-06 10:22:27 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-integration-response") %>>
<a href="/docs/providers/aws/r/api_gateway_integration_response.html">aws_api_gateway_integration_response</a>
Add aws_api_gateway_resource resource
2016-03-05 23:14:35 +01:00
</li>
Add aws_api_gateway_method resource
2016-03-05 23:15:22 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-method") %>>
<a href="/docs/providers/aws/r/api_gateway_method.html">aws_api_gateway_method</a>
</li>
Add aws_api_gateway_method_response resource
2016-03-05 23:16:16 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-method-response") %>>
<a href="/docs/providers/aws/r/api_gateway_method_response.html">aws_api_gateway_method_response</a>
</li>
provider/aws: Sort API Gateway resources alphabetically
2016-03-06 10:22:27 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-model") %>>
<a href="/docs/providers/aws/r/api_gateway_model.html">aws_api_gateway_model</a>
Add aws_api_gateway_integration resource
2016-03-05 23:16:52 +01:00
</li>
provider/aws: Sort API Gateway resources alphabetically
2016-03-06 10:22:27 +01:00
<li<%= sidebar_current("docs-aws-resource-api-gateway-resource") %>>
<a href="/docs/providers/aws/r/api_gateway_resource.html">aws_api_gateway_resource</a>
</li>
<li<%= sidebar_current("docs-aws-resource-api-gateway-rest-api") %>>
<a href="/docs/providers/aws/r/api_gateway_rest_api.html">aws_api_gateway_rest_api</a>
Add aws_api_gateawy_integration_response resource
2016-03-05 23:17:21 +01:00
</li>
Add aws_api_gateway_rest_api resource
2016-03-05 23:13:38 +01:00
</ul>
</li>
provider/aws: Add docs for aws_cloudformation_stack
2015-07-07 00:45:47 +02:00
<li<%= sidebar_current(/^docs-aws-resource-cloudformation/) %>>
<a href="#">CloudFormation Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-cloudformation-stack") %>>
<a href="/docs/providers/aws/r/cloudformation_stack.html">aws_cloudformation_stack</a>
</li>
</ul>
</li>
Add docs for aws_iam_role
2015-05-12 23:09:46 +02:00
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>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-cloudwatch-metric-alarm") %>>
<a href="/docs/providers/aws/r/cloudwatch_metric_alarm.html">aws_cloudwatch_metric_alarm</a>
</li>
docs/aws: Whitespaces removed
2015-12-23 16:19:28 +01:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
</ul>
</li>
Implement AWS IAM resources - Users - Groups - Roles - Inline policies for the above three - Instance profiles - Managed policies - Access keys This is most of the data types provided by IAM. There are a few things missing, but the functionality here is probably sufficient for 95% of the cases. Makes a dent in #28.
2015-02-06 16:34:24 +01:00
Added the documentation for the CodeCommit repository
2015-10-30 22:38:13 +01:00
<li<%= sidebar_current(/^docs-aws-resource-codecommit/) %>>
<a href="#">CodeCommit Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-codecommit-repository") %>>
<a href="/docs/providers/aws/r/code_commit_repository.html">aws_codecommit_repository</a>
</li>
</ul>
</li>
CodeDeploy links to the AWS provider sidebar. Missed these when merging #2783.
2015-10-21 17:44:19 +02:00
<li<%= sidebar_current(/^docs-aws-resource-codedeploy/) %>>
<a href="#">CodeDeploy Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-codedeploy-app") %>>
<a href="/docs/providers/aws/r/codedeploy_app.html">aws_codedeploy_app</a>
</li>
<li<%= sidebar_current("docs-aws-resource-codedeploy-deployment-group") %>>
<a href="/docs/providers/aws/r/codedeploy_deployment_group.html">aws_codedeploy_deployment_group</a>
</li>
</ul>
</li>
provider/aws: Add docs for aws_directory_service_directory
2015-09-13 18:58:22 +02:00
<li<%= sidebar_current(/^docs-aws-resource-directory-service/) %>>
<a href="#">Directory Service Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-directory-service-directory") %>>
<a href="/docs/providers/aws/r/directory_service_directory.html">aws_directory_service_directory</a>
</li>
</ul>
</li>
Implement AWS IAM resources - Users - Groups - Roles - Inline policies for the above three - Instance profiles - Managed policies - Access keys This is most of the data types provided by IAM. There are a few things missing, but the functionality here is probably sufficient for 95% of the cases. Makes a dent in #28.
2015-02-06 16:34:24 +01:00
Added the documentation for the CodeCommit repository
2015-10-30 22:38:13 +01:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current(/^docs-aws-resource-dynamodb/) %>>
<a href="#">DynamoDB Resources</a>
<ul class="nav nav-visible">
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-dynamodb-table") %>>
<a href="/docs/providers/aws/r/dynamodb_table.html">aws_dynamodb_table</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
</ul>
</li>
Docs: Sort AWS resources alphabetically
2015-05-30 16:36:04 +02:00
docs: Make a separate Elastic Beanstalk section in sidebar
2016-03-08 10:52:39 +01:00
<li<%= sidebar_current(/^docs-aws-resource-(ami|app|autoscaling|ebs|elb|eip|instance|launch|lb|proxy|spot|volume|placement|key-pair)/) %>>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<a href="#">EC2 Resources</a>
<ul class="nav nav-visible">
aws docs: Sort resources alphabetically
2015-06-13 22:12:24 +02:00
Three resources for AWS AMIs. AWS provides three different ways to create AMIs that each have different inputs, but once they are complete the same management operations apply. Thus these three resources each have a different "Create" implementation but then share the same "Read", "Update" and "Delete" implementations.
2015-08-30 06:35:45 +02:00
<li<%= sidebar_current("docs-aws-resource-ami") %>>
<a href="/docs/providers/aws/r/ami.html">aws_ami</a>
</li>
<li<%= sidebar_current("docs-aws-resource-ami-copy") %>>
<a href="/docs/providers/aws/r/ami_copy.html">aws_ami_copy</a>
</li>
<li<%= sidebar_current("docs-aws-resource-ami-from-instance") %>>
<a href="/docs/providers/aws/r/ami_from_instance.html">aws_ami_from_instance</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-app-cookie-stickiness-policy") %>>
<a href="/docs/providers/aws/r/app_cookie_stickiness_policy.html">aws_app_cookie_stickiness_policy</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-autoscaling-group") %>>
<a href="/docs/providers/aws/r/autoscaling_group.html">aws_autoscaling_group</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Adding the docs for the autoscaling_lifecycle_hook
2015-10-04 00:52:29 +02:00
<li<%= sidebar_current("docs-aws-resource-autoscaling-lifecycle-hook") %>>
Add support for aws autoscaling lifecycle hooks.
2015-09-29 08:09:45 +02:00
<a href="/docs/providers/aws/r/autoscaling_lifecycle_hooks.html">aws_autoscaling_lifecycle_hook</a>
Adding the docs for the autoscaling_lifecycle_hook
2015-10-04 00:52:29 +02:00
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-autoscaling-notification") %>>
<a href="/docs/providers/aws/r/autoscaling_notification.html">aws_autoscaling_notification</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-autoscaling-policy") %>>
<a href="/docs/providers/aws/r/autoscaling_policy.html">aws_autoscaling_policy</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Adding a resource for aws_autoscaling_schedule
2015-12-11 19:13:52 +01:00
<li<%= sidebar_current("docs-aws-resource-autoscaling-schedule") %>>
<a href="/docs/providers/aws/r/autoscaling_schedule.html">aws_autoscaling_schedule</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-ebs-volume") %>>
<a href="/docs/providers/aws/r/ebs_volume.html">aws_ebs_volume</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-eip") %>>
<a href="/docs/providers/aws/r/eip.html">aws_eip</a>
</li>
Added docs, tests, and updated SQS code
2015-05-15 22:09:20 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-elb") %>>
<a href="/docs/providers/aws/r/elb.html">aws_elb</a>
</li>
Docs: Sort AWS resources alphabetically
2015-05-30 16:36:04 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-instance") %>>
<a href="/docs/providers/aws/r/instance.html">aws_instance</a>
</li>
Docs: Sort AWS resources alphabetically
2015-05-30 16:36:04 +02:00
website: Sort aws_key_pair in the sidebar
2016-02-18 15:22:14 +01:00
<li<%= sidebar_current("docs-aws-resource-key-pair") %>>
<a href="/docs/providers/aws/r/key_pair.html">aws_key_pair</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-launch-configuration") %>>
<a href="/docs/providers/aws/r/launch_configuration.html">aws_launch_configuration</a>
</li>
provider/aws: spot_instance_request This is an iteration on the great work done by @dalehamel in PRs #2095 and #2109. The core team went back and forth on how to best model Spot Instance Requests, requesting and then rejecting a separate-resource implementation in #2109. After more internal discussion, we landed once again on a separate resource to model Spot Instance Requests. Out of respect for @dalehamel's already-significant donated time, with this I'm attempting to pick up the work to take this across the finish line. Important architectural decisions represented here: * Spot Instance Requests are always of type "persistent", to properly match Terraform's declarative model. * The spot_instance_request resource exports several attributes that are expected to be constantly changing as the spot market changes: spot_bid_status, spot_request_state, and instance_id. Creating additional resource dependencies based on these attributes is not recommended, as Terraform diffs will be continually generated to keep up with the live changes. * When a Spot Instance Request is deleted/canceled, an attempt is made to terminate the last-known attached spot instance. Race conditions dictate that this attempt cannot guarantee that the associated spot instance is terminated immediately. Implementation notes: * This version of aws_spot_instance_request borrows a lot of common code from aws_instance. * In order to facilitate borrowing, we introduce `awsInstanceOpts`, an internal representation of instance details that's meant to be shared between resources. The goal here would be to refactor ASG Launch Configurations to use the same struct. * The new aws_spot_instance_request acc. test is passing. * All aws_instance acc. tests remain passing.
2015-06-05 17:12:09 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-lb-cookie-stickiness-policy") %>>
<a href="/docs/providers/aws/r/lb_cookie_stickiness_policy.html">aws_lb_cookie_stickiness_policy</a>
</li>
provider/aws: Add Security Group Rule as a top level resource - document conflict with sg rules and sg in-line rules - for this to work, ingress rules need to be computed
2015-04-20 20:38:21 +02:00
provider/aws: Add docs for aws_placement_group
2015-10-08 21:58:03 +02:00
<li<%= sidebar_current("docs-aws-resource-placement-group") %>>
<a href="/docs/providers/aws/r/placement_group.html">aws_placement_group</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-proxy-protocol-policy") %>>
<a href="/docs/providers/aws/r/proxy_protocol_policy.html">aws_proxy_protocol_policy</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
provider/aws: Document Volume Attachment
2015-05-28 17:33:20 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-spot-instance-request") %>>
<a href="/docs/providers/aws/r/spot_instance_request.html">aws_spot_instance_request</a>
</li>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-volume-attachment") %>>
<a href="/docs/providers/aws/r/volume_attachment.html">aws_volume_attachment</a>
</li>
</ul>
</li>
aws: Add docs for aws_vpn_connection resources.
2015-05-01 18:23:39 +02:00
Docs: Sort AWS resources alphabetically
2015-05-30 16:36:04 +02:00
docs/aws: Fix highlighting of ECR in sidebar
2015-12-23 16:21:22 +01:00
<li<%= sidebar_current(/^docs-aws-resource-(ecs|ecr)/) %>>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<a href="#">ECS Resources</a>
<ul class="nav nav-visible">
Docs: Sort AWS resources alphabetically
2015-05-30 16:36:04 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-ecs-cluster") %>>
<a href="/docs/providers/aws/r/ecs_cluster.html">aws_ecs_cluster</a>
</li>
providers/aws: Implements DHCP Options Set support.
2015-04-28 21:57:05 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-ecs-service") %>>
<a href="/docs/providers/aws/r/ecs_service.html">aws_ecs_service</a>
</li>
aws: Add documentation for VPN connection routes.
2015-05-04 18:21:22 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-ecs-task-definition") %>>
<a href="/docs/providers/aws/r/ecs_task_definition.html">aws_ecs_task_definition</a>
</li>
provider/aws: mention us-east-1 in ECR docs and tests ECR is only available in us-east-1 for now. Also added missing sidebar links for ECR resources. /cc @nextrevision
2015-12-22 22:59:17 +01:00
<li<%= sidebar_current("docs-aws-resource-ecr-repository") %>>
<a href="/docs/providers/aws/r/ecr_repository.html">aws_ecr_repository</a>
</li>
<li<%= sidebar_current("docs-aws-resource-ecr-repository-policy") %>>
<a href="/docs/providers/aws/r/ecr_repository_policy.html">aws_ecr_repository_policy</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
</ul>
</li>
provider/aws: Add docs for EFS resources
2015-09-16 13:44:41 +02:00
<li<%= sidebar_current(/^docs-aws-resource-efs/) %>>
<a href="#">EFS Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-efs-file-system") %>>
<a href="/docs/providers/aws/r/efs_file_system.html">aws_efs_file_system</a>
</li>
<li<%= sidebar_current("docs-aws-resource-efs-mount-target") %>>
<a href="/docs/providers/aws/r/efs_mount_target.html">aws_efs_mount_target</a>
</li>
</ul>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current(/^docs-aws-resource-elasticache/) %>>
<a href="#">ElastiCache Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-elasticache-cluster") %>>
<a href="/docs/providers/aws/r/elasticache_cluster.html">aws_elasticache_cluster</a>
</li>
<li<%= sidebar_current("docs-aws-resource-elasticache-parameter-group") %>>
<a href="/docs/providers/aws/r/elasticache_parameter_group.html">aws_elasticache_parameter_group</a>
</li>
<li<%= sidebar_current("docs-aws-resource-elasticache-security-group") %>>
<a href="/docs/providers/aws/r/elasticache_security_group.html">aws_elasticache_security_group</a>
</li>
<li<%= sidebar_current("docs-aws-resource-elasticache-subnet-group") %>>
<a href="/docs/providers/aws/r/elasticache_subnet_group.html">aws_elasticache_subnet_group</a>
</li>
</ul>
</li>
docs: Make a separate Elastic Beanstalk section in sidebar
2016-03-08 10:52:39 +01:00
<li<%= sidebar_current(/^docs-aws-resource-elastic-beanstalk/) %>>
<a href="#">Elastic Beanstalk Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-elastic-beanstalk-application") %>>
<a href="/docs/providers/aws/r/elastic_beanstalk_application.html">aws_elastic_beanstalk_application</a>
</li>
<li<%= sidebar_current("docs-aws-resource-elastic-beanstalk-configuration-template") %>>
<a href="/docs/providers/aws/r/elastic_beanstalk_configuration_template.html">aws_elastic_beanstalk_configuration_template</a>
</li>
<li<%= sidebar_current("docs-aws-resource-elastic-beanstalk-environment") %>>
<a href="/docs/providers/aws/r/elastic_beanstalk_environment.html">aws_elastic_beanstalk_environment</a>
</li>
</ul>
</li>
provider/aws: Add docs for aws_elasticsearch_domain
2015-10-02 00:13:32 +02:00
<li<%= sidebar_current(/^docs-aws-resource-elasticsearch/) %>>
<a href="#">ElasticSearch Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-elasticsearch-domain") %>>
<a href="/docs/providers/aws/r/elasticsearch_domain.html">aws_elasticsearch_domain</a>
</li>
</ul>
</li>
Adding the the docs for the Glacier Vault resource Updating the glacier docs to include a link to the AWS developer guide
2015-09-16 00:32:54 +02:00
<li<%= sidebar_current(/^docs-aws-resource-glacier/) %>>
<a href="#">Glacier Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-glacier-vault") %>>
<a href="/docs/providers/aws/r/glacier_vault.html">aws_glacier_vault</a>
</li>
</ul>
</li>
provider/aws: Add docs for aws_elasticsearch_domain
2015-10-02 00:13:32 +02:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current(/^docs-aws-resource-iam/) %>>
<a href="#">IAM Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-iam-access-key") %>>
<a href="/docs/providers/aws/r/iam_access_key.html">aws_iam_access_key</a>
</li>
provider/aws: Add docs for AWS Account Password Policy resource
2016-02-06 12:41:52 +01:00
<li<%= sidebar_current("docs-aws-resource-iam-account-password-policy") %>>
<a href="/docs/providers/aws/r/iam_account_password_policy.html">aws_iam_account_password_policy</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-iam-group") %>>
<a href="/docs/providers/aws/r/iam_group.html">aws_iam_group</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-group-policy") %>>
<a href="/docs/providers/aws/r/iam_group_policy.html">aws_iam_group_policy</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-group-membership") %>>
<a href="/docs/providers/aws/r/iam_group_membership.html">aws_iam_group_membership</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-instance-profile") %>>
<a href="/docs/providers/aws/r/iam_instance_profile.html">aws_iam_instance_profile</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-policy") %>>
<a href="/docs/providers/aws/r/iam_policy.html">aws_iam_policy</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-policy-attachment") %>>
<a href="/docs/providers/aws/r/iam_policy_attachment.html">aws_iam_policy_attachment</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-role") %>>
<a href="/docs/providers/aws/r/iam_role.html">aws_iam_role</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-role-policy") %>>
<a href="/docs/providers/aws/r/iam_role_policy.html">aws_iam_role_policy</a>
</li>
provider/aws: Add docs for aws_iam_saml_provider
2015-09-02 21:01:36 +02:00
<li<%= sidebar_current("docs-aws-resource-iam-saml-provider") %>>
<a href="/docs/providers/aws/r/iam_saml_provider.html">aws_iam_saml_provider</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current("docs-aws-resource-iam-server-certificate") %>>
<a href="/docs/providers/aws/r/iam_server_certificate.html">aws_iam_server_certificate</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-user") %>>
<a href="/docs/providers/aws/r/iam_user.html">aws_iam_user</a>
</li>
<li<%= sidebar_current("docs-aws-resource-iam-user-policy") %>>
<a href="/docs/providers/aws/r/iam_user_policy.html">aws_iam_user_policy</a>
</li>
</ul>
</li>
<li<%= sidebar_current(/^docs-aws-resource-kinesis/) %>>
<a href="#">Kinesis Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-kinesis-stream") %>>
<a href="/docs/providers/aws/r/kinesis_stream.html">aws_kinesis_stream</a>
</li>
</ul>
</li>
Adding the documentation for the Kinesis Firehose Delivery Stream
2015-11-10 17:43:34 +01:00
<li<%= sidebar_current(/^docs-aws-resource-kinesis-firehose/) %>>
<a href="#">Kinesis Firehose Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-kinesis-firehose-delivery-stream") %>>
<a href="/docs/providers/aws/r/kinesis_firehose_delivery_stream.html">aws_kinesis_firehose_delivery_stream</a>
</li>
</ul>
</li>
Add missing documentation link for #4093
2015-12-01 14:47:12 +01:00
<li<%= sidebar_current(/^docs-aws-resource-lambda/) %>>
<a href="#">Lambda Resources</a>
<ul class="nav nav-visible">
docs: Add missing link to aws_lambda_alias
2016-01-25 13:46:32 +01:00
<li<%= sidebar_current("docs-aws-resource-lambda-alias") %>>
<a href="/docs/providers/aws/r/lambda_alias.html">aws_lambda_alias</a>
</li>
Add missing documentation link for #4093
2015-12-01 14:47:12 +01:00
<li<%= sidebar_current("docs-aws-resource-lambda-function") %>>
<a href="/docs/providers/aws/r/lambda_function.html">aws_lambda_function</a>
</li>
website: Fix missing sidebar_current
2016-03-06 15:51:25 +01:00
<li<%= sidebar_current("docs-aws-resource-lambda-event-source-mapping") %>>
Add missing documentation link for #4093
2015-12-01 14:47:12 +01:00
<a href="/docs/providers/aws/r/lambda_event_source_mapping.html">aws_lambda_event_source_mapping</a>
</li>
provider/aws: Add docs for aws_lambda_permission
2016-01-25 15:20:07 +01:00
<li<%= sidebar_current("docs-aws-resource-lambda-permission") %>>
<a href="/docs/providers/aws/r/lambda_permission.html">aws_lambda_permission</a>
</li>
Add missing documentation link for #4093
2015-12-01 14:47:12 +01:00
</ul>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
Prepare for adding OpsWorks resources. Here we add an OpsWorks client instance to the central client bundle and establish a new documentation section, both of which will be fleshed out in subsequent commits that add some OpsWorks resources.
2015-05-11 05:20:17 +02:00
<li<%= sidebar_current(/^docs-aws-resource-opsworks/) %>>
<a href="#">OpsWorks Resources</a>
<ul class="nav nav-visible">
Various AWS OpsWorks layer resource types. A "Layer" is a particular service that forms part of the infrastructure for a set of applications. Some layers are application servers and others are pure infrastructure, like MySQL servers or load balancers. Although the AWS API only has one type called "Layer", it actually has a number of different "soft" types that each have slightly different validation rules and extra properties that are packed into the Attributes map. To make the validation rule differences explicit in Terraform, and to make the Terraform structure more closely resemble the OpsWorks UI than its API, we use a separate resource type per layer type, with the common code factored out into a shared struct type.
2015-06-01 07:07:32 +02:00
<li<%= sidebar_current("docs-aws-resource-opsworks-custom-layer") %>>
<a href="/docs/providers/aws/r/opsworks_custom_layer.html">aws_opsworks_custom_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-ganglia-layer") %>>
<a href="/docs/providers/aws/r/opsworks_ganglia_layer.html">aws_opsworks_ganglia_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-haproxy-layer") %>>
<a href="/docs/providers/aws/r/opsworks_haproxy_layer.html">aws_opsworks_haproxy_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-java-app-layer") %>>
<a href="/docs/providers/aws/r/opsworks_java_app_layer.html">aws_opsworks_java_app_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-memcached-layer") %>>
<a href="/docs/providers/aws/r/opsworks_memcached_layer.html">aws_opsworks_memcached_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-mysql-layer") %>>
<a href="/docs/providers/aws/r/opsworks_mysql_layer.html">aws_opsworks_mysql_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-nodejs-app-layer") %>>
<a href="/docs/providers/aws/r/opsworks_nodejs_app_layer.html">aws_opsworks_nodejs_app_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-php-app-layer") %>>
<a href="/docs/providers/aws/r/opsworks_php_app_layer.html">aws_opsworks_php_app_layer</a>
</li>
<li<%= sidebar_current("docs-aws-resource-opsworks-rails-app-layer") %>>
<a href="/docs/providers/aws/r/opsworks_rails_app_layer.html">aws_opsworks_rails_app_layer</a>
</li>
aws_opswork_stack resource type. "Stack" is the root concept in OpsWorks, and acts as a container for a number of different "layers" that each provide some service for an application. A stack isn't very interesting on its own, but it needs to be created before any layers can be created.
2015-05-11 05:21:03 +02:00
<li<%= sidebar_current("docs-aws-resource-opsworks-stack") %>>
<a href="/docs/providers/aws/r/opsworks_stack.html">aws_opsworks_stack</a>
</li>
Various AWS OpsWorks layer resource types. A "Layer" is a particular service that forms part of the infrastructure for a set of applications. Some layers are application servers and others are pure infrastructure, like MySQL servers or load balancers. Although the AWS API only has one type called "Layer", it actually has a number of different "soft" types that each have slightly different validation rules and extra properties that are packed into the Attributes map. To make the validation rule differences explicit in Terraform, and to make the Terraform structure more closely resemble the OpsWorks UI than its API, we use a separate resource type per layer type, with the common code factored out into a shared struct type.
2015-06-01 07:07:32 +02:00
<li<%= sidebar_current("docs-aws-resource-opsworks-static-web-layer") %>>
<a href="/docs/providers/aws/r/opsworks_static_web_layer.html">aws_opsworks_static_web_layer</a>
</li>
Prepare for adding OpsWorks resources. Here we add an OpsWorks client instance to the central client bundle and establish a new documentation section, both of which will be fleshed out in subsequent commits that add some OpsWorks resources.
2015-05-11 05:20:17 +02:00
</ul>
</li>
provider/aws: Docs for RDS Cluster, Cluster Instance
2015-08-04 23:24:55 +02:00
<li<%= sidebar_current(/^docs-aws-resource-(db|rds)/) %>>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<a href="#">RDS Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-db-instance") %>>
<a href="/docs/providers/aws/r/db_instance.html">aws_db_instance</a>
</li>
<li<%= sidebar_current("docs-aws-resource-db-parameter-group") %>>
<a href="/docs/providers/aws/r/db_parameter_group.html">aws_db_parameter_group</a>
</li>
<li<%= sidebar_current("docs-aws-resource-db-security-group") %>>
<a href="/docs/providers/aws/r/db_security_group.html">aws_db_security_group</a>
</li>
<li<%= sidebar_current("docs-aws-resource-db-subnet-group") %>>
<a href="/docs/providers/aws/r/db_subnet_group.html">aws_db_subnet_group</a>
</li>
provider/aws: Docs for RDS Cluster, Cluster Instance
2015-08-04 23:24:55 +02:00
<li<%= sidebar_current("docs-aws-resource-rds-cluster") %>>
<a href="/docs/providers/aws/r/rds_cluster.html">aws_rds_cluster</a>
</li>
<li<%= sidebar_current("docs-aws-resource-rds-cluster-instance") %>>
<a href="/docs/providers/aws/r/rds_cluster_instance.html">aws_rds_cluster_instance</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
</ul>
</li>
Adding the documentation for the Redshift security groups Creation of the schema, CRUD and acceptance tests for Redshift Parameter Group
2015-11-12 00:37:56 +01:00
<li<%= sidebar_current(/^docs-aws-resource-redshift/) %>>
<a href="#">Redshift Resources</a>
<ul class="nav nav-visible">
Adding the documentation for the AWS Redshift Subnet Group resource also removed the notion of tags from the redshift security group and parameter group documentation until that has been implemented Redshift Cluster CRUD and acceptance tests Removing the Acceptance test for the Cluster Updates. You cannot delete a cluster immediately after performing an operation on it. We would need to add a lot of retry logic to the system to get this test to work Adding some schema validation for RedShift cluster Adding the last of the pieces of a first draft of the Redshift work - this is the documentation
2015-11-12 10:45:22 +01:00
<li<%= sidebar_current("docs-aws-resource-redshift-cluster") %>>
<a href="/docs/providers/aws/r/redshift_cluster.html">aws_redshift_cluster</a>
</li>
Adding the documentation for the Redshift Parameter Groups Changed the aws_redshift_security_group and aws_redshift_parameter_group to remove the tags from the schema. Tags are a little bit more complicated than originally though - I will revisit this later Then added the schema, CRUD functionality and basic acceptance tests for aws_redshift_subnet_group Adding an acceptance test for the Update of subnet_ids in AWS Redshift Subnet Group
2015-11-12 02:10:57 +01:00
<li<%= sidebar_current("docs-aws-resource-redshift-parameter-group") %>>
<a href="/docs/providers/aws/r/redshift_parameter_group.html">aws_redshift_parameter_group</a>
</li>
Adding the documentation for the Redshift security groups Creation of the schema, CRUD and acceptance tests for Redshift Parameter Group
2015-11-12 00:37:56 +01:00
<li<%= sidebar_current("docs-aws-resource-redshift-security-group") %>>
<a href="/docs/providers/aws/r/redshift_security_group.html">aws_redshift_security_group</a>
</li>
Adding the documentation for the AWS Redshift Subnet Group resource also removed the notion of tags from the redshift security group and parameter group documentation until that has been implemented Redshift Cluster CRUD and acceptance tests Removing the Acceptance test for the Cluster Updates. You cannot delete a cluster immediately after performing an operation on it. We would need to add a lot of retry logic to the system to get this test to work Adding some schema validation for RedShift cluster Adding the last of the pieces of a first draft of the Redshift work - this is the documentation
2015-11-12 10:45:22 +01:00
<li<%= sidebar_current("docs-aws-resource-redshift-subnet-group") %>>
<a href="/docs/providers/aws/r/redshift_subnet_group.html">aws_redshift_subnet_group</a>
</li>
Adding the documentation for the Redshift security groups Creation of the schema, CRUD and acceptance tests for Redshift Parameter Group
2015-11-12 00:37:56 +01:00
</ul>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<li<%= sidebar_current(/^docs-aws-resource-route53/) %>>
<a href="#">Route53 Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-route53-delegation-set") %>>
<a href="/docs/providers/aws/r/route53_delegation_set.html">aws_route53_delegation_set</a>
</li>
<li<%= sidebar_current("docs-aws-resource-route53-health-check") %>>
<a href="/docs/providers/aws/r/route53_health_check.html">aws_route53_health_check</a>
</li>
<li<%= sidebar_current("docs-aws-resource-route53-record") %>>
<a href="/docs/providers/aws/r/route53_record.html">aws_route53_record</a>
</li>
<li<%= sidebar_current("docs-aws-resource-route53-zone") %>>
<a href="/docs/providers/aws/r/route53_zone.html">aws_route53_zone</a>
</li>
<li<%= sidebar_current("docs-aws-resource-route53-zone-association") %>>
<a href="/docs/providers/aws/r/route53_zone_association.html">aws_route53_zone_association</a>
</li>
docs/aws: Whitespaces removed
2015-12-23 16:19:28 +01:00
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
</ul>
</li>
<li<%= sidebar_current(/^docs-aws-resource-s3/) %>>
<a href="#">S3 Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-s3-bucket") %>>
<a href="/docs/providers/aws/r/s3_bucket.html">aws_s3_bucket</a>
</li>
update docs
2015-07-30 22:17:16 +02:00
<li<%= sidebar_current("docs-aws-resource-s3-bucket-object") %>>
<a href="/docs/providers/aws/r/s3_bucket_object.html">aws_s3_bucket_object</a>
</li>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
</ul>
</li>
<li<%= sidebar_current(/^docs-aws-resource-sns/) %>>
<a href="#">SNS Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-sns-topic") %>>
<a href="/docs/providers/aws/r/sns_topic.html">aws_sns_topic</a>
</li>
<li<%= sidebar_current("docs-aws-resource-sns-topic-subscription") %>>
<a href="/docs/providers/aws/r/sns_topic_subscription.html">aws_sns_topic_subscription</a>
</li>
</ul>
</li>
<li<%= sidebar_current(/^docs-aws-resource-sqs/) %>>
<a href="#">SQS Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-sqs-queue") %>>
<a href="/docs/providers/aws/r/sqs_queue.html">aws_sqs_queue</a>
</li>
</ul>
</li>
[docs] aws_key_pair resource documentation should be listed in "ec2" and not in "vpc"
2016-01-29 17:43:14 +01:00
<li<%= sidebar_current(/^docs-aws-resource-(customer|flow|internet-gateway|main-route|network|route-|security-group|subnet|vpc|vpn)/) %>>
Split AWS provider topics by service. With so many AWS provider resources, the docs are getting pretty hard to navigate. This is particularly true due to the mismatch of some resources encoding the service name (like aws_route53_record) but some others ignoring it (like aws_subnet) or using a generic prefix (like aws_db_instance), which causes an alphabetical ordering to muddle up all of the services. Since the AWS UI and docs are themselves oriented around services, most users should be familiar with the service brands and understand which resources belong to which service. Thus this categorization follows the primary categorization used within the AWS Console, preferring EC2-VPC over EC2-Classic-style bucketing.
2015-07-23 10:01:13 +02:00
<a href="#">VPC Resources</a>
<ul class="nav nav-visible">
<li<%= sidebar_current("docs-aws-resource-customer-gateway") %>>
<a href="/docs/providers/aws/r/customer_gateway.html">aws_customer_gateway</a>
</li>
<li<%= sidebar_current("docs-aws-resource-flow-log") %>>
<a href="/docs/providers/aws/r/flow_log.html">aws_flow_log</a>
</li>
<li<%= sidebar_current("docs-aws-resource-internet-gateway") %>>
<a href="/docs/providers/aws/r/internet_gateway.html">aws_internet_gateway</a>
</li>
<li<%= sidebar_current("docs-aws-resource-main-route-table-assoc") %>>
<a href="/docs/providers/aws/r/main_route_table_assoc.html">aws_main_route_table_association</a>
</li>
provider/aws: Add aws_nat_gateway Resource
2015-12-18 08:20:13 +01:00
<li<%= sidebar_current("docs-aws-resource-nat-gateway") %>>
<a href="/docs/providers/aws/r/nat_gateway.html">aws_nat_gateway</a>
</li>
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") %>>
<a href="/docs/providers/aws/r/vpc_peering.html">aws_vpc_peering</a>
</li>
<li<%= sidebar_current("docs-aws-resource-vpn-connection") %>>
<a href="/docs/providers/aws/r/vpn_connection.html">aws_vpn_connection</a>
</li>
<li<%= sidebar_current("docs-aws-resource-vpn-connection-route") %>>
<a href="/docs/providers/aws/r/vpn_connection_route.html">aws_vpn_connection_route</a>
</li>
<li<%= sidebar_current("docs-aws-resource-vpn-gateway") %>>
<a href="/docs/providers/aws/r/vpn_gateway.html">aws_vpn_gateway</a>
</li>
</ul>
</li>
</ul>
</div>
<% end %>
<%= yield %>
website: add ebs_volume
2015-04-29 05:49:21 +02:00
<% end %>