Skip to content

Import since 1.6.0 does'nt work Params.count of type string #133

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

Closed
cp3hu opened this issue Dec 3, 2018 · 9 comments
Closed

Import since 1.6.0 does'nt work Params.count of type string #133

cp3hu opened this issue Dec 3, 2018 · 9 comments
Labels

Comments

@cp3hu
Copy link

cp3hu commented Dec 3, 2018

Hi since 1.6.0 release we have another cast issue on Params.count.
I cannot confirm that is was not present on previous version, cause i had the json: cannot unmarshal number into Go struct field Screenboard.height of type string which is fixed by 1.6.0

Do you know if there is any workaround about ?

Thanks

Terraform Version

Terraform v0.11.10
provider.datadog: version = "1.6"

Affected Resource(s)

datadog_screenboard

Terraform Configuration Files

resource "datadog_screenboard" "datadog_screenboard" {
}

Expected Behavior

Imported screenboard

Actual Behavior

json: cannot unmarshal number into Go struct field Params.count of type string

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:
terraform import datadog_screenboard.datadog_screenboard id

References

@officel
Copy link

officel commented Dec 13, 2018

I wrote #105 . and #117 has not solved it.

After that the test was repeated.I got some conclusions

  • use only terraform is OK
  • manual on DataDog Site is NG
  • Cause is that the value of "width" will change from "0" to "100%"(string)
    • maybe set by DataDog Site self

use DataDog API see https://docs.datadoghq.com/ja/api/#screenboards-put
like a width = 1024 (!="100%") called.

I can import any screenboards. try it.

@officel
Copy link

officel commented Dec 13, 2018

sorry,
I do not know the target field, so check it out.
Params.count is what?

@agoulart0
Copy link

agoulart0 commented Jan 15, 2019

I'm having another issue similar to this casting, but with the width field:

Error: datadog_screenboard.my_service_screenboard (import id: 554985): import datadog_screenboard.my_service_screenboard (id: 554985): json: cannot unmarshal string into Go struct field Screenboard.width of type int

When I curl the screen, I get

"width": "100%"

which is not an Int. Is this related, right?

Terraform v0.11.11
+ provider.datadog v1.6.0

@2rs2ts
Copy link

2rs2ts commented Jan 23, 2019

@agoulart0 yeah, you have to pull the json from the API, edit it, PUT it, and then you can import.

also of note is that this doesn't just affect import, it also affects all refreshing, so please don't use the datadog UI unless you want to risk problems :)

the width attribute of the datadog resource should probably be changed to a string type to allow for the "100%" string...

@marcomusso
Copy link

Hi all, I get the workaround for the width field but what about the original Params.count of type string error?

@wbuiejr
Copy link

wbuiejr commented Feb 25, 2019

@2rs2ts , how do you edit the JSON? Put quotes around the integers to turn them into strings?

@2rs2ts
Copy link

2rs2ts commented Feb 25, 2019

@wbuiejr it's been a while but yeah I believe that's what I did.

@nmuesch
Copy link
Contributor

nmuesch commented May 27, 2020

Hey, I apologize for the delay here. There were some changes on the api side a little while back that should help to avoid this issue going forward where these wouldn't be returned into the Terraform state. It may require any change to be made to the dashboard via the UI to have these fields be properly updated, then any terraform import/plan/apply should properly work.

Is this still an issue being faced? Additionally, the newer dashboard resource has some extra validations around them that should help avoid these types of issues in the future.

@nmuesch
Copy link
Contributor

nmuesch commented Jun 15, 2020

Hey, apologies again for the delay on this one. As this issue should be resolved I'll go ahead and close this out for now. Let us know if you experience any further issues with this.

@nmuesch nmuesch closed this as completed Jun 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants