b90fb25321
Traditionally we've preferred to release new language features in major
releases only, because we can then use the beta cycle to gather feedback
on the feature and learn about any usability challenges or other
situations we didn't consider during our design in time to make those
changes before inclusion in a stable release.
This "experiments" feature is intended to decouple the feedback cycle for
new features from the major release rhythm, and thus allow us to release
new features in minor releases by first releasing them as experimental for
a minor release or two, adjust for any feedback gathered during that
period, and then finally remove the experiment gate and enable the feature
for everyone.
The intended model here is that anything behind an experiment gate is
subject to breaking changes even in patch releases, and so any module
using these experimental features will be broken by a future Terraform
upgrade.
The behavior implemented here is:
- Recognize a new "experiments" setting in the "terraform" block which
allows module authors to explicitly opt in to experimental features.
terraform {
experiments = [resource_for_each]
}
- Generate a warning whenever loading a module that has experiments
enabled, to avoid accidentally depending on experimental features and
thus risking unexpected breakage on next Terraform upgrade.
- We check the enabled experiments against the configuration at module
load time, which means that experiments are scoped to a particular
module. Enabling an experiment in one module does not automatically
enable it in any other module.
This experiments mechanism is itself an experiment, and so I'd like to
use the resource for_each feature to trial it. Because any configuration
using experiments is subject to breaking changes, we are free to adjust
this experiments feature in future releases as we see fit, but once
for_each is shipped without an experiment gate we'll be blocked from
making significant changes to it until the next major release at least.
|
||
|---|---|---|
| .github | ||
| addrs | ||
| backend | ||
| builtin | ||
| command | ||
| communicator | ||
| config | ||
| configs | ||
| contrib | ||
| dag | ||
| digraph | ||
| docs | ||
| e2e | ||
| examples | ||
| experiments | ||
| flatmap | ||
| helper | ||
| httpclient | ||
| internal | ||
| lang | ||
| moduledeps | ||
| plans | ||
| plugin | ||
| providers | ||
| provisioners | ||
| registry | ||
| repl | ||
| scripts | ||
| state | ||
| states | ||
| terraform | ||
| tfdiags | ||
| tools | ||
| vendor | ||
| version | ||
| website | ||
| .gitignore | ||
| .go-version | ||
| .hashibot.hcl | ||
| .tfdev | ||
| .travis.yml | ||
| BUILDING.md | ||
| CHANGELOG.md | ||
| checkpoint.go | ||
| CODEOWNERS | ||
| commands.go | ||
| config.go | ||
| Dockerfile | ||
| go.mod | ||
| go.sum | ||
| help.go | ||
| LICENSE | ||
| main_test.go | ||
| main.go | ||
| Makefile | ||
| panic.go | ||
| plugins.go | ||
| README.md | ||
| signal_unix.go | ||
| signal_windows.go | ||
| synchronized_writers.go | ||
| version.go | ||
Terraform
- Website: https://www.terraform.io
- Mailing list: Google Groups
Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.
The key features of Terraform are:
-
Infrastructure as Code: Infrastructure is described using a high-level configuration syntax. This allows a blueprint of your datacenter to be versioned and treated as you would any other code. Additionally, infrastructure can be shared and re-used.
-
Execution Plans: Terraform has a "planning" step where it generates an execution plan. The execution plan shows what Terraform will do when you call apply. This lets you avoid any surprises when Terraform manipulates infrastructure.
-
Resource Graph: Terraform builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources. Because of this, Terraform builds infrastructure as efficiently as possible, and operators get insight into dependencies in their infrastructure.
-
Change Automation: Complex changesets can be applied to your infrastructure with minimal human interaction. With the previously mentioned execution plan and resource graph, you know exactly what Terraform will change and in what order, avoiding many possible human errors.
For more information, see the introduction section of the Terraform website.
Getting Started & Documentation
If you're new to Terraform and want to get started creating infrastructure, please checkout our Getting Started guide, available on the Terraform website.
All documentation is available on the Terraform website:
Developing Terraform
This repository contains only Terraform core, which includes the command line interface and the main graph engine. Providers are implemented as plugins that each have their own repository in the terraform-providers organization on GitHub. Instructions for developing each provider are in the associated README file. For more information, see the provider development overview.
To learn more about compiling Terraform and contributing suggested changes, please refer to the contributing guide.