Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing default value to nil for TypeInt in Optional parameter [ Custom Providers Development ] #90

Closed
jeyanthimuthuram opened this issue Nov 30, 2017 · 9 comments
Labels
enhancement New feature or request

Comments

@jeyanthimuthuram
Copy link

Hi,

Questions

  • Is there any way to set default value of TypeInt to nil in optional parameters in Schema?

  • Is there any way to find the value is provided by user or it is auto-set ?

Terraform Version

Terraform v0.10.8

Use Case

I am building custom terraform provider ,there I need to call api's through the configuration

  • I have some default values , that is optional I and even if I am passing nothing in tf configuration it is making them zero.
  • And I can't able to filter while making json request ( because that field may or may not hold zero , and I don't know any way to differentiate between user input and auto-set value)

Please suggest a way I can make it work ?

@apparentlymart
Copy link
Contributor

Hi @jeyanthimuthuram,

At the moment the provider framework does not have any concept of "null", because Terraform itself doesn't either. However, work is in progress to address this via a new type system that's being introduced as part of the new version of the configuration language. It will, unfortunately, take a few steps before we reach the point where we can expose this capability to the provider framework (it has to be supported throughout Terraform Core first) but we are planning to do this, for the reason you stated.

In the mean time, existing resources usually either use the zero value as an alias for "unset" or, when that isn't possible, make the attribute required and have the user set the default explicitly, or use some sort of "impossible value" as the default value, such as using -1 for a number that can only be positive in the remote API.

@ahl
Copy link

ahl commented Sep 18, 2018

Is the new type system still in the works? If not, it seems like there's a simple, if inelegant, fix for this problem.

@mildwonkey
Copy link
Contributor

Yes, we are hard at work on the new type system. It's going to be the terraform 0.12 release, which you can read about in the terraform blog.

@apparentlymart
Copy link
Contributor

An additional note on that, though: The Terraform 0.12 release will introduce the concept of "null" at the core level, but in order to preserve compatibility with older releases the provider SDK will not immediately get such support: for some time period, providers will need to work with both Terraform 0.12 and prior versions to allow for gradual upgrades.

We do still intend to add support for null attributes at the SDK level, but this will be a separate change to the SDK itself (driven by our other team that maintains the SDK) that will come at a later point where new provider releases will no longer be compatible with Terraform versions earlier than 0.12. The exact schedule for that is not yet determined, since we want to wait and see how the upgrade process for 0.12 itself goes before imposing an effective deadline on it.

@ahl
Copy link

ahl commented Sep 18, 2018

0.12 looks pretty great: love the for loops and conditionals. Good to know that the new type system won't be immediately available to providers.

@hashibot hashibot transferred this issue from hashicorp/terraform Sep 26, 2019
@hashibot hashibot added the enhancement New feature or request label Oct 2, 2019
@Sh4d1
Copy link

Sh4d1 commented Oct 4, 2019

Any news regarding this issue?

@jakubpech
Copy link

We tried to use V2 SDK from branch "version2" today and run d.Set(key, nil). Unfortunately, the value of the key was still the zero value (false, 0, ""). Will proper handling of nil be a part of initial V2 SDK release or is it something more complex, which will be added later?

@paultyng
Copy link
Contributor

paultyng commented Apr 2, 2020

The best tracking issue will be #261. The v2 branch paves the way for us to start exposing this new functionality, but we will probably do it via new code paths to not break existing code.

@paultyng paultyng closed this as completed Apr 2, 2020
@ghost
Copy link

ghost commented May 3, 2020

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.

@ghost ghost locked and limited conversation to collaborators May 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

9 participants