logdna / terraform-provider-logdna

Terraform provider to simplify creation of views, preset alerts and other resources in LogDNA!
https://registry.terraform.io/providers/logdna/logdna/latest
MIT License
11 stars 12 forks source link

Logdna_archive configuration flow can return vague error that needs additional request data in returned error #74

Open jimlindeman opened 1 year ago

jimlindeman commented 1 year ago

We're seeing a case where the IBM Terraform schematics uses the code in https://github.com/logdna/terraform-provider-logdna/blob/main/logdna/resource_archive.go#L167 to enable configuration of an COS based archive storage, but the error we're getting back:

 2022/09/23 18:46:02 Terraform apply | logdna_archive.config: Creating...
 2022/09/23 18:46:03 Terraform apply | 
 2022/09/23 18:46:03 Terraform apply | Error: POST https://api.us-east.logging.cloud.ibm.com/v1/config/archiving, status 400 NOT OK! {"error":"Invalid input/settings.","code":"BadRequest","status":"error"}

The input passed into the provider seems correct:

 2022/09/23 18:45:55 Terraform apply |   resource "logdna_archive" "config" {
 2022/09/23 18:45:55 Terraform apply |        id          = (known after apply)
 2022/09/23 18:45:55 Terraform apply |        integration = "ibm"
 2022/09/23 18:45:55 Terraform apply | 
 2022/09/23 18:45:55 Terraform apply |        ibm_config {
 2022/09/23 18:45:55 Terraform apply |           apikey             = "<REDACTED>"
 2022/09/23 18:45:55 Terraform apply |           bucket             = "eis-fd4b-arch2-service-logs-archive"
 2022/09/23 18:45:55 Terraform apply |           endpoint           = "s3.us-east.cloud-object-storage.appdomain.cloud"
 2022/09/23 18:45:55 Terraform apply |           resourceinstanceid = "crn:v1:bluemix:public:logdna:us-east:a/4fd48221017bc3ae0817c113177133df:5cb260a4-732d-4def-ae01-449e47cf322d::"
 2022/09/23 18:45:55 Terraform apply |        }
 2022/09/23 18:45:55 Terraform apply |    }

Unfortunately, this error coming back from logDNA doesn't give us any indication as to what field/setting was 'invalid', so we need the provider to log more information in these error cases like the request body or if there is a trace-id response header from logDNA, we should be logging that.

i.e. we need the current code doing:

        body, err := req.MakeRequest()
    if err != nil {
        return diag.FromErr(err)
    }

to do something like:

        body, err := req.MakeRequest()
    if err != nil {
            if strings.Contains(err.Error(), 'BadRequest') {
                b, err := json.Marshal(req)
                // trace-id headers, if any from logDNA, have to be collected in error path of MakeRequest()
                return diag.ErrorF("Input error in request to configure logDNA archive. Err: %s , Request: %s", err.Error(), b)
            } else {
        return diag.FromErr(err)
            }
    }
jimlindeman commented 1 year ago

I looked more and see trace-ids (if logdna provides them in response headers) could then be logged in https://github.com/logdna/terraform-provider-logdna/blob/master/logdna/request.go#L78.

May make more sense to log the request body there based on certain res.StatusCode values, so that necessary debug information is available for multiple types of calls.