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

UpdateLogpushJobParams: logpull_options field is not removed on apply #1709

Open
2 tasks done
dloebl opened this issue Apr 9, 2024 · 0 comments
Open
2 tasks done
Labels
needs-triage Indicates an issue or PR lacks a `triage: foo` label and requires one.

Comments

@dloebl
Copy link

dloebl commented Apr 9, 2024

Confirmation

  • My issue isn't already found on the issue tracker.
  • I have replicated my issue using the latest version of the library and it is still present.

cloudflare-go version

v0.92.0

Go environment

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/dbl/Library/Caches/go-build'
GOENV='/Users/dbl/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/dbl/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/dbl/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.22.2/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.22.2/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.2'
GCCGO='gccgo'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/Users/dbl/src/github.com/dloebl/terraform-provider-cloudflare/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/gk/qjn1dfx905dbtbtmcd68rtrm0000gn/T/go-build3464282275=/tmp/go-build -gno-record-gcc-switches -fno-common'

Expected output

That logpull_options is gone after the apply.

Actual output

See step 5: logpull_options is still there after the apply:

$ terraform plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # cloudflare_logpush_job.example will be updated in-place
  ~ resource "cloudflare_logpush_job" "example" {
        id                          = "[redacted]"
      - logpull_options             = "fields=RayID&timestamps=rfc3339&CVE-2021-44228=false" -> null
        name                        = "example"
        # (8 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

PUT request (TF_LOG=trace output):

PUT /client/v4/zones/[redacted]/logpush/jobs/[redacted] HTTP/1.1
Host: api.cloudflare.com
User-Agent: terraform-provider-cloudflare/dev terraform-plugin-sdk/2.32.0 terraform/1.7.5
Content-Type: application/json
Body: {"dataset":"http_requests","enabled":false,"name":"example","output_options":{"field_names":[],"output_type":"ndjson","record_prefix":"{","record_suffix":"}","field_delimiter":",","timestamp_format":"unixnano","sample_rate":1,"CVE-2021-44228":false},"destination_conf":"[redacted]","frequency":"high"}

^ As you can see logpull_options isn't sent, but the PUT doesn't seem to overwrite the resource - it behaves more like a PATCH.

Code demonstrating the issue

resource "cloudflare_logpush_job" "example" {
  enabled = false
  zone_id = "1234"
  name = "example"
  destination_conf = "https://example.com"
  dataset = "http_requests"
  logpull_options = "fields=RayID&timestamps=rfc3339&CVE-2021-44228=false"
  output_options {
  }
}

^ Replace zone_id and destination_conf with actual values

Steps to reproduce

  1. Apply the demonstration code to a test zone (replace zone_id and destination_conf with actual values)
  2. Remove the logpull_options field from the resource
  3. terraform plan
  4. terraform apply
  5. terraform plan

References

No response

@dloebl dloebl added the needs-triage Indicates an issue or PR lacks a `triage: foo` label and requires one. label Apr 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-triage Indicates an issue or PR lacks a `triage: foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

2 participants
@dloebl and others