As of this commit this provider has only logical resources that allow
the creation of private keys, self-signed certs and certificate requests.
These can be useful when creating other resources that use TLS
certificates, such as AWS Elastic Load Balancers.
Later it could grow to include support for real certificate provision from
CAs using the LetsEncrypt ACME protocol, once it is stable.
These new functions allow Terraform to be used for network address space
planning tasks, and make it easier to produce reusable modules that
contain or depend on network infrastructure.
For example:
- cidrsubnet allows an aws_subnet to derive its
CIDR prefix from its parent aws_vpc.
- cidrhost allows a fixed IP address for a resource to be assigned within
an address range defined elsewhere.
- cidrnetmask provides the dotted-decimal form of a prefix length that is
accepted by some systems such as routing tables and static network
interface configuration files.
The bulk of the work here is done by an external library I authored called
go-cidr. It is MIT licensed and was implemented primarily for the purpose
of using it within Terraform. It has its own unit tests and so the unit
tests within this change focus on simple success cases and on the correct
handling of the various error cases.
Fixing basic acceptance test.
Adding warning to website about mixed mode.
Adding exists to aws_route.
Adding acceptance test for changing destination_cidr_block.
* Update init docs to be correct, and provide an example.
* Update remote config docs to provide more details about the Consul
backend and to provide another example.
Since we merged this so that the community could collaborate on
improvements, I thought it would be prudent to inform potential users of
the status of the provider so they know what to expect.
aws_lb_cookie_stickiness_policy.elbland: Error creating LBCookieStickinessPolicy: ValidationError: Policy name cannot contain characters that are not letters, or digits or the dash.
The `ForceDelete` parameter was getting sent to the upstream API call,
but only after we had already finished draining instances from
Terraform, so it was a moot point by then.
This fixes that by skipping the drain when force_delete is true, and it
also simplifies the field config a bit:
* set a default of false to simplify the logic
* remove `ForceNew` since there's no need to replace the resource to
flip this value
* pull a detail comment from code into the docs
Why:
* The current example for passing arguments to a local script does not
include making the uploaded file executable.
This change addresses the need by:
* Add a step to make the uploaded script executable to the example
showing how to pass arguments to an uploaded script.
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.
"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.
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.
For those accustomed to running commands via a shell it may not be clear
why this argument is a list and what the elements of that list should be.
Hopefully giving an example will help people understand what is expected.
This is in response to the misunderstanding discovered in #3011.
There isn't any precedent for abbreviating words in the interpolation
function names, and it may not be clear to all users what "enc" and "dec"
are short for, so instead we'll prefer to spell out the whole words for
improved readability.
BSick7