Official OpenStack clients commonly support specifing a client
certificate/key to enable SSL client authentication when communicating
with OpenStack services. This patch enables such feature in Terraform
with new parameters and environment variables:
* 'cert' provider parameter or OS_CERT env variable to specify client
certificate file,
* 'key' provider parameter or OS_KEY env variable to specify client
certificate private key file.
* Add Triton Metadata modification AccTest.
The test starts the basic machine and then adds the metadata field
user_data.
Test fails if the user_data field does not match what we expect
OR it times out.
Related to hashicorp/terraform#6148
* Fix the non-convergence of Triton metadata changes
The code waiting for the entire Machine Metadata to "deep equal" the Terraform
metadata modifications. These two sets will only be the same if the user
changes all metadata fields of the resource before calling `apply`.
Closeshashicorp/terraform#6148
It can come in handy to be able to mount ISOs programmatically.
For instance if you're developing a custom appliance (that automatically installs itself on the hard drive volume)
that you want to automatically test on every successful build (given the ISO is uploaded to the vmware datastore).
There are probably lots of other reasons for using this functionality.
* provider/aws: Fix hashing on CloudFront certificate parameters
Adding necessary type assertion to values on the viewer_certificate hash
function to ensure that certain fields are indeed not zero string
values, versus simply zero interface{} values (aka nil, as is such for a
map[string]interface{}).
* provider/aws: CloudFront complex structure error handling
Handle errors better on calls to d.Set() in the
aws_cloudfront_distribution, namely in flattenDistributionConfig(). Also
caught a bug in the setting of the origin attribute, was incorrectly
attempting to set origins.
* provider/aws: Pass pointers to set CloudFront primitives
Change a few d.Set() for primitives in aws_cloudfront_distribution and
aws_cloudfront_origin_access_identity to use the pointer versus a
dereference.
* docs: Fix CloudFront examples formatting
Ran each example thru terraform fmt to fix indentation.
* provider/aws: Remove delete retention on CloudFront tests
To play better with Travis and not bloat the test account with disabled
distributions.
Disable-only functionality has been retained - one can enable it with
the TF_TEST_CLOUDFRONT_RETAIN environment variable.
* provider/aws: CloudFront delete waiter error handling
The call to resourceAwsCloudFrontDistributionWaitUntilDeployed() on
deletion of CloudFront distributions was not trapping error messages,
causing issues with waiter failure.
hil.Eval() now returns (hil.EvaluationResult, error) instead of (value,
type, error). This commit updates the call sites, but retains all
previous behaviour. Tests are also updated.
This commit patches a few acceptance tests in order to get them to
pass under OpenStack Mitaka.
The devstack dev environment script has also been updated to reflect
OpenStack Mitaka as well as the new Terraform dependency vendoring.
* provider/fastly: Add support for managing Headers
Adds support for managing Headers in a Fastly configuration.
* update acc test
* update website with example of adding a header block
* 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
According to the libpq documentation, "prefer" is the default in the
underlying library and so setting a different default in the Terraform
layer would be a breaking change for existing users of this provider
whose servers do not have TLS correctly configured.
The docs now link to the libpq manual's discussion of the security
implications of each of the ssl_mode options, so the user can understand
the limitations of the "prefer" default and can make an informed decision
about which setting is appropriate for their situation.
As with several other sensitive values in Opsworks, the API returns a
placeholder value rather than a nil. To avoid writing the placeholder
value into the state we just skip updating the password on read, letting
whatever value was in the state persist.
This means that Terraform can't detect configuration drift where someone
has changed the password via some other means, but Terraform will still
be able to recognize changes to the password made within Terraform itself
due to the "last-written" value in the state.
This fixes#6192.
Other separate changes to testAccOpsworksStackConfigNoVpcCreate caused
this to begin failing because it was attempting to create a stack with
an empty name.
Previously in Update we would only set req.CustomJson if a non-empty
value was provided in the config. It seems that the Opsworks API considers
a null CustomJson to mean "do not change" rather than "set to empty",
so we need to explicitly set the empty string in the request body in
order to successfully remove an already-configured custom JSON.
This introduces a provider for Cobbler. Cobbler manages bare-metal
deployments and, to some extent, virtual machines. This initial
commit supports the following resources: distros, profiles, systems,
kickstart files, and snippets.
* 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.
* Improve testing of CodeDeploy DeploymentGroup Trigger Configs
- ensure updates to trigger_events are applied
- assert changes to trigger_target_arn
* Retry CodeDeploy DeploymentGroup when Trigger Config SNS Topic is not available
- increase retries from 2 => 5
* Don't Base64-encode EC2 userdata if it is already Base64 encoded
The user data may be Base64 encoded already - for example, if it has been
generated by a template_cloudinit_config resource.
* Add encoded user_data to aws_instance acceptance test
* Issue #2174 Check that InternetGateway exists before returning from creation
Fix some random InvalidInternetGatewayID.NotFound errors
* Issue #2174 Reuse IGStateRefreshFunc
* Issue #2174 Need to wait for creation before setting tags
Update github.com/joyent/gosdc/...
Test does the minimum described in hashicorp/terraform#6109, i.e.
- Start a small instance, t4-standard-128M
- Check firewall is enabled
- Change configuration to disable firewall
- Check firewall is disabled.
Fixes#6119.
* provider/aws: CodeDeploy Deployment Group Triggers
- Create a Trigger to Send Notifications for AWS CodeDeploy Events
- Update aws_codedeploy_deployment_group docs
* Refactor validateTriggerEvent function and test
- also rename TestAccAWSCodeDeployDeploymentGroup_triggerConfiguration test
* Enhance existing Deployment Group integration tests
- by using built in resource attribute helpers
- these can get quite verbose and repetitive, so passing the resource to a function might be better
- can't use these (yet) to assert trigger configuration state
* Unit tests for conversions between aws TriggerConfig and terraform resource schema
- buildTriggerConfigs
- triggerConfigsToMap
* provider/aws: Add more Randomization to DB Parameter Group Tests, to avoid collisions
* provider/aws: Add more randomization to Autoscaling group tests
We have a curtesy function in place allowing you to specify both a
`name` of `ID`. But in order for the graph to be build correctly when
you recreate or taint stuff that other resources depend on, we need to
reference the `ID` and *not* the `name`.
So in order to enforce this and by that help people to not make this
mistake unknowingly, I deprecated all the parameters this allies to and
changed the logic, docs and tests accordingly.
Added the ability to set the "privacy" of a github_team resource so all teams won't automatically set to private.
* Added the privacy argument to github_team
* Refactored parameter validation to be general for any argument
* Updated testing
This is the first step in removing the config dependency on "project".
This change is backwards-compatible because the value for this new
attribute defaults to the value from the provider.
This commit enables the ability to authenticate to OpenStack by way
of a Keystone Token. Tokens can provide a way to use Terraform and
OpenStack with an expiring, temporary credential. The token will need
to be generated out of band from Terraform.
* provider/aws: test empty plan with sns_topic policy with random order
If we setup a sns_topic policy with a policy with a different order
to the one set by the AWS API, terraform plan will be not empty between
runs.
* provider/aws: normalize json policy for sns topic
For the policy attribute of the resource aws_sns_topic, AWS returns the policy
in JSON format with the fields in a different order.
If we store and compare the values without normalizing, terraform
will unnecesary trigger and update of the resource.
To avoid that, we must add a normalization function in the StateFunc of
the policy attribute and also when we read the attribute from AWS.
This commit adds a no_gateway attribute. When set, the subnet will
not have a gateway. This is different than not specifying a
gateway_ip since that will cause a default gateway of .1 to be used.
This behavior mirrors the OpenStack Neutron command-line tool.
Fixes#6031
When calling AssociateAddress, the PrivateIpAddress parameter must be
used to select which private IP the EIP should associate with, otherwise
the EIP always associates with the _first_ private IP.
Without this parameter, multiple EIPs couldn't be assigned to a single
ENI. Includes covering test and docs update.
Fixes#2997
Previously the format string was using %#v, which prints the whole data structure given.
Instead we want to use %s to get the string representation of the error.
This fixes#6038.
Normalise the event_pattern of the aws_cloudwatch_event_rule resource
before uploading it to AWS.
AWS seems to accept a event_pattern with a JSON with new lines, but then
the rule does not seem to work. Creating the rule in the AWS console works,
but will setup the pattern as a json without newlines or spaces, and
display a formatted JSON.
Previously, resizing would only work if the flavor_id changed and
would create an error if the flavor_name changes. This commit fixes
this behavior.
It also quickly refactors the getFlavorID function to use
Gophercloud's IDFromName function. getFlavorID was the basis of
IDFromName so the exact same code is used.
Fixes#5780
Fix retry after removing associations by correctly checking and returning an
error. This should patch the VPC/Resource leak in our nightly acceptance tests.
It turns out all other providers use `ip_address` where the CloudStack
provider uses `ipaddress`. To make this more consistent this PR
deprecates `ipaddress` and adds `ip_address` where needed…
This new resource is an alternative to consul_keys that manages all keys
under a given prefix, rather than arbitrary single keys across the entire
store.
The key advantage of this resource over consul_keys is that it is able to
detect and delete keys that are added outside of Terraform, whereas
consul_keys is only able to detect changes to keys it is explicitly
managing.
The provider should, when working on a new repository without branches:
* Able to create a new repository even with default_branch defined.
* Able to create a new repository without default_branch, and do not fail
if default_branch is defined.
In AWS codecommit the default branch must have a value unless there are
no branches created, in which case it is not possible to set it to any value.
We query the existing branches and do not update the default branch
if there are none defined remotely.
This solves the issue of the initial creation of the repository with a
resource with `default_branch` defined.
AWS changed their error message, which was being used for detection of
the specific error that indicates we need to wait for IAM propagation.
Behavior is covered by a test now.
Fixes#5862
Unlike SimpleScaling policies, StepScaling policies require one or more
"steps", which are interval ranges in which a tracked metric can lie.
Policies can then execute scaling adjustments wedded to these steps.
This commit also adds a slew of additional policy attributes which are
only applicable to step policies.
The ignore_changes diff filter was stripping out attributes on Create
but the diff was still making it down to the provider, so Create would
end up missing attributes, causing a full failure if any required
attributes were being ignored.
In addition, any changes that required a replacement of the resource
were causing problems with `ignore_chages`, which didn't properly filter
out the replacement when the triggering attributes were filtered out.
Refs #5627
This applies the same fix to `digitalocean_ssh_key` as #5588 applies to
droplets. Fixes#5402. The report there gives weight to my theory that
this occurs when there are transport issues.
Here we also introduce a `test` provider meant as an aid to exposing
via automated tests issues involving interactions between
`helper/schema` and Terraform core.
This has been helpful so far in diagnosing `ignore_changes` problems,
and I imagine it will be helpful in other contexts as well.
We'll have to be careful to prevent the `test` provider from becoming a
dumping ground for poorly specified tests that have a clear home
elsewhere. But for bug exposure I think it's useful to have.
This brings across the following resources for Triton from the
joyent/triton-terraform repository, and converts them to the canonical
Terraform style, introducing Terraform-style documentation and
acceptance tests which run against the live API rather than the local
APIs:
- triton_firewall_rule
- triton_machine
- triton_key
This brings across the following resources for Triton from the
joyent/triton-terraform repository, and converts them to the canonical
Terraform style, introducing Terraform-style documentation and
acceptance tests which run against the live API rather than the local
APIs:
- triton_firewall_rule
- triton_machine
- triton_key
Needed to truncate the identifier for SQL Server engines to keep it at
max 15 chars per the docs. Not a full UUID going into it, but should be
"unique enough" to not matter in practice.
Modified the basic test to use the generated value. Other tests are
still working w/ explicitly specified identifiers.
`publicly_accessible` to be changed
Also updated the AWS Go SDK from 1.1.9 -> 1.1.12 as this was required to
allow the new behavior for the Redshift API
Usage of a helper function was assuming that an error would be returned
in a not found condition, when in fact a nil pointer was
returned.
Attached test crashes w/o fix, passes with it.
Fixes#5350
Refs #5418
This should be quite helpful in debugging aws-sdk-go operations.
Required some tweaking around the `helper/logging` functions to expose an
`IsDebugOrHigher()` helper for us to use.
Turns out the BC code allowed users to move from `filename` to
`template` to squash the warning without having to switch from template
paths to template contents.
Here we warn when `template` is specified as a path so we can remove the
functionality in the future and remove this source of confusion.
refs #3732
Previously this resource managed the set of keys as a whole rather than
the individual keys, and so it was unable to recognize when a particular
managed key is removed and delete just that one key from Consul.
Here this is addressed by recognizing that each key actually has its own
lifecycle, and detecting when individual keys are added and removed
without replacing the entire consul_keys instance.
Additionally this restores the behavior of updating the "value" attribute
on read, but restricts it only to blocks that already had a value so as
to avoid the quirkiness seen previously when we updated blocks that were
intended to be read-only. Updating the value is important now, because we
rely on this to detect and repair discrepancies between values stored in
Consul and values given in the configuration.
This change produces a change in the handling of the "delete" attribute.
Before it was considered only when the entire consul_keys resource was
deleted, but now it is considered also when a particular key block is
removed from within a resource.
This deals with some of the quirks of interacting with the Consul API,
with the goal of making the consul_keys resource implementation, and
later the consul_keys data source, less noisy to read.
Change the `RetryFunc` from a plain `error` return type to a
specialized `RetryError` which must decide whether it is
retryable or not.
Add `RetryableError` / `NonRetryableError` factory functions that
callers are meant to use to build up these errors.
This makes it eminently clear whether or not a given error is
retryable from inside the client code.
Goal here is to _not_ change any behavior, simply reflect the
existing behavior with the new, clearer, API.
Cedric Brandily