@core-code Traditionally, the offline installer for the latest release has been made available two weeks after the online installer. I’m not sure why it fell so far behind this time, but given that most of the world was in crisis mode in and around April, I don’t blame them for falling behind. A new offline installer for 1.9.1 was released today, so I’m hopeful this is a sign that things are back on track over at Fujitsu. I’ve opened a new PR to bump the version: https://github.com/Homebrew/homebrew-cask-drivers/pull/1917.

Created with brew bump-cask-pr.

Created with brew bump-cask-pr.

Hello, I have created and configured the oracle db endpoint. DBA's have provided me a package to use as part of creation statement for creating new user. The package accepts old user, new user and password as arguments to the function.

Below is the vault command and the creation statement.

./vault write database/roles/my-role db_name=mydb creation_statements="EXECUTE PKG_USER.create_user('olduser','{{name}}','{{password}}');" default_ttl="10m" max_ttl="10m"

When I execute the vault command for creating credential, I am getting invalid sql statement error. I tried different combinations by removing quotes using BEGIN END instead of EXECUTE but it didn't help. Appreciate your insight into this.

vault read database/creds/my-role

Error reading database/creds/my-role: Error making API request.

URL: GET https://127.0.0.1:8200/v1/database/creds/my-role Code: 500. Errors:

• 1 error occurred: * rpc error: code = Unknown desc = ORA-00900: invalid SQL statement

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

Current Terraform Version

v0.13.5

Use-cases

In my CI/CD pipeline I want to apply changes only when certain conditions are met (e.g. changes to certain resources are not allowed without confirmation).

Attempted Solutions

I would like to use terraform show -json my.tfplan | jq 'select(.change.actions != ["no-op"]) | .address' | grep ... to inspect the Terraform Plan and abort the CI/CD deployment if certain conditions are violated.

Proposal

Include jq (<4MB) in the docker.io/hashicorp/terraform:light container image, so I can use it in my CI/CD pipeline in the deployment step.

I could roll my own container image, but then I would have to maintain it and keep it updated with changes to the docker.io/hashicorp/terraform:light image. It seems easier and also more useful to the general public to include jq with terraform, given that it already contains git and ssh, which are likely even larger than jq.

References

I could not find similar requests.

Hi @devurandom! Thanks for this feature request.

We don't plan to include any additional software in the official Docker images. You're right that git is already included, a historical decision that we are now bound to for backward compatibility, but each new piece of software we might add is another bit of surface area where we need to worry about upgrading it when new releases become available, supporting it if it turns out to be built/installed incorrectly, etc.

The Terraform docker images are intended for direct use with terraform run to run just Terraform, and any other software that happens to be installed in the images today is an implementation detail subject to change. If you are using a CI system which uses Docker images as the primary encapsulation for jobs, I would recommend using our images directly because future versions may change which other software is available in ways that could impact your CI jobs, such as no longer including grep or including a different version of grep with different features.

Instead, I'd suggest to build your own image based on an operating system image that includes the software you want. terraform executables are statically linked so you should be able to copy one into any Linux docker image and have it work, regardless of other details of the OS such as which libc it uses.

While I appreciate your use-case, it's not a problem our Docker images are intended to be used for and we don't have the resources to support a full operating system base image for CI systems.

Thanks again for this feature request! If you have any follow-up questions about building docker images with Terraform installed, feel free to start a topic in our community forum.

I have problem like this:

dynamic` "vpc" {
    for_each  = each.value["vpc_id"] != null ? [{
      vpc_id  = each.value["vpc_id"]
    }] : []

    content {
      vpc_id  = vpc.value["vpc_id"]
    }
  }

I need to generate the vpc block only if vpc_id is part of the map It works fine if I specify:

vpc_id = null

or

vpc_id = module.vpc.vpc_id

otherwise if vpc_id is missing it will thow error:

  16:     for_each  = each.value["vpc_id"] != null ? [{
    |----------------
    | each.value is object with 2 attributes

The given key does not identify an element in this collection value.

It works but I need to have the vpc_id = null

Codecov Report

Merging #27026 (a56e492) into master (f6d6446) will decrease coverage by 0.00%. The diff coverage is n/a.

We've historically made statements like this in response to requests for more customization to the terraform fmt behavior, but the documentation itself was somewhat vague about the intended goals of this command.

This is an attempt to be more explicit that consistency between codebases is the primary goal of this command, and that the examples in the Terraform documentation are our main guide for what is "idiomatic style" when adding additional rules over time.

Nothing here is intended to be new policy, but instead as codifying positions we've taken elsewhere in the past in the hope of allowing users to decide how (and whether) they wish to make use of this tool.

I've marked this for backport into the v0.14 branch because Terraform v0.14 includes some new rules to do things like strip out redundant interpolation syntax. This is only a documentation change, so it won't affect any behaviors of the v0.14.0 final release as compared to the release candidate.

It happens to have been quite a few major releases since we made any significant changes to terraform fmt, because we've been keeping busy with other things, and so I'm updating these docs in anticipation of newer users encountering a formatting behavior change for the first time and wondering what the deal is with that.

I don't have a real answer for you on why a narrower type fixes the issue, except that Terraform's type unification algorithm (which is responsible for these type conversions & validations) is doing a very complex job and there are probably some corner cases that it doesn't quite handle. At the moment I still think this is probably a bug, which is why I'm leaving this issue open. It's good to know there's at least a workaround!

As an aside, I believe that {} is a valid value for a variable of type map(map(any))—it certainly seems to work in my tests.

@rigrassm Thank you for the PR! I am not super familiar with these providers, but I'll see what we can do about getting this PR merged and integrated into Consul.

If you have a moment, I would love to hear your thoughts about https://github.com/hashicorp/consul/issues/9100 (as comments on that issue). If that solution seems viable to you I think it would solve this problem by removing the need to update providers and get them integrated into multiple tools.

Codecov Report

Merging #10306 (fdb36e3) into master (73b7499) will increase coverage by 0.00%. The diff coverage is 0.00%.

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

Corey Hickey seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you already have a GitHub account, please add the email address used for this commit to your account.

_{Have you signed the CLA already but the status is still pending? Recheck it.}

This avoids the error:

• guest_additions_mode has to be 'disable' when communicator = 'none'.

...when the following are set: "communicator": "none", "guest_additions_mode": "attach",

This particular combination of parameters is valid; for example, in my case, a kickstart post-install script mounts the CD image from /dev/sr1 and runs the installer, without needing any intervention from packer itself.

From my reading of the documentation, it appears that the "upload" mode would indeed require a communicator, so I change the logic to check for that specifically.

This is very interesting. @alisdair Can you explain to me, why making it a more distinct type works? Honestly I don't understand that. The reason why I wanted to use map(any) with a custom validation instead of map(map(any)) is that I cannot put an empty map {} into it then. But okay, a problem I can live with.

I love the simplification by using ... by the way. Didn't understand how to use it until just now.

Thanks!!!

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}

Corrects a typo (documenatation -> documentation)

Labels

<!-- Check any labels that apply to this PR. Or, if you have repo permissions, assign a real label and omit this section. -->

• [ ] inaccuracy
• [ ] clarification
• [ ] new docs
• [ x] cosmetic bug - fixing broken text or markup
• [ ] enhancement - changing the website's behavior/layout

After making all changes to a cask, verify:

• [x] brew audit --cask {{cask_file}} is error-free.
• [x] brew style --fix {{cask_file}} reports no offenses.
• [x] There are no open pull requests for the same update.
• [x] The submission is for a stable version or documented exception.

Thank you @Raphx.

Current Terraform Version

v0.13.5

Use-cases

In my CI/CD pipeline I want to apply changes only when certain conditions are met (e.g. changes to certain resources are not allowed without confirmation).

Attempted Solutions

I would like to use terraform show -json my.tfplan | jq 'select(.change.actions != ["no-op"]) | .address' | grep ... to inspect the Terraform Plan and abort the CI/CD deployment if certain conditions are violated.

Proposal

Include jq (<4MB) in the docker.io/hashicorp/terraform:light container image, so I can use it in my CI/CD pipeline in the deployment step.

I could roll my own container image, but then I would have to maintain it and keep it updated with changes to the docker.io/hashicorp/terraform:light image. It seems easier and also useful to the general public to include jq with terraform, given that it already contains git and ssh, which are likely even larger than jq.

References

I could not find similar requests.

<!-- Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

If your issue relates to a specific Terraform provider, please open it in the provider's own repository. The index of providers is at https://github.com/terraform-providers.

To fix problems, we need clear reproduction cases - we need to be able to see it happen locally. A reproduction case is ideally something a Terraform Core engineer can git-clone or copy-paste and run immediately, without inventing any details or context.

• A short example can be directly copy-pasteable; longer examples should be in separate git repositories, especially if multiple files are needed
• Please include all needed context. For example, if you figured out that an expression can cause a crash, put the expression in a variable definition or a resource
• Set defaults on (or omit) any variables. The person reproducing it should not need to invent variable settings
• If multiple steps are required, such as running terraform twice, consider scripting it in a simple shell script. For example, see this case. Providing a script can be easier than explaining what changes to make to the config between runs.
• Omit any unneeded complexity: remove variables, conditional statements, functions, modules, providers, and resources that are not needed to trigger the bug
• When possible, use the null resource provider rather than a real provider in order to minimize external dependencies. We know this isn't always feasible. The Terraform Core team doesn't have deep domain knowledge in every provider, or access to every cloud platform for reproduction cases.

-->

Terraform Version

<!--- Run terraform version to show the version, and paste the result between the ``` marks below.

If you are not running the latest version of Terraform, please try upgrading because your issue may have already been fixed. -->

v0.13.5

Terraform Configuration Files

<!-- Paste the relevant parts of your Terraform configuration between the ``` marks below.

For Terraform configs larger than a few resources, or that involve multiple files, please make a GitHub repository that we can clone, rather than copy-pasting multiple files in here. For security, you can also encrypt the files using our GPG public key at https://www.hashicorp.com/security. -->

...

https://github.com/Azure/sap-hana/tree/kimforss_add_separator_where_missing

Debug Output

<!-- Full debug output can be obtained by running Terraform with the environment variable TF_LOG=trace. Please create a GitHub Gist containing the debug output. Please do not paste the debug output in the issue, since debug output is long.

Debug output may contain sensitive information. Please review it before posting publicly, and if you are concerned feel free to encrypt the files using the HashiCorp security public key. -->

Crash Output

<!-- If the console output indicates that Terraform crashed, please share a link to a GitHub Gist containing the output of the crash.log file. --> https://gist.github.com/rukawata/8f34ce3853f8cfecd5a0d74e9beef0d2

Expected Behavior

<!-- What should have happened? --> Not crash.

Actual Behavior

<!-- What actually happened? --> Terraform crash.

Steps to Reproduce

<!-- Please list the full steps required to reproduce the issue, for example:

1. terraform init
2. terraform apply -->
3. terraform apply
4. terraform plan

Additional Context

<!-- Are there anything atypical about your situation that we should know? For example: is Terraform running in a wrapper script or in a CI system? Are you passing any unusual command line options or environment variables to opt-in to non-default behavior? -->

References

<!-- Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• #6017

-->

Duplicate of #26702