Open DanielRis opened 3 years ago
Hi @DanielRis
The GET /servicesNS/-/-/data/inputs/http?count=-1&output_mode=json
request helps terraform find the Splunk HEC resource object across different app workspaces. Once that initial response is successful then there is a subsequent request that is made with the retrieved owner (eg: nobody) and app (eg: search) to find the resource for that particular workspace.
The reason for failure in your case could be different. I tried the above stanza and did not run into any issues.
You can check if your resource exists or if it was created manually then it needs to be imported first.
Hi @anushjay , the resource is created by the provider, but after creating the HEC token, a subsequent httpEventCollectorInputRead
is executed (https://github.com/splunk/terraform-provider-splunk/blob/master/splunk/resource_splunk_inputs_http_event_collector.go#L110) which sends a GET request to /servicesNS/-/-/data/inputs/http
.
And this fails for my Splunk deployment. So the HEC token exists after creation, the provider thinks it was not successful because the httpEventCollectorInputRead
fails. I will try to get more details next week.
Hello,
when I try to create a HEC token using a configuration like this I see this, maybe unwanted behavior.
The provider then sends a POST request to
POST /servicesNS/nobody/splunk_httpinput/data/inputs/http/some-name?count=-1&output_mode=json HTTP/1.1
which creates the HEC token on the Splunk side.TF then tries to read the provider via API from
GET /servicesNS/-/-/data/inputs/http?count=-1&output_mode=json HTTP/1.1
which returns a empty result and TF throws an errorError: Unable to find resource:
Is the request path here maybe incorrect? According to documentation it should be
GET /servicesNS/nobody/search/data/inputs/http?count=-1&output_mode=json HTTP/1.1
(https://docs.splunk.com/Documentation/Splunk/latest/RESTREF/RESTinput#data.2Finputs.2Fhttp)After changing theses values in https://github.com/splunk/terraform-provider-splunk/blob/master/client/inputs_http_event_collector.go#L63, the provider behaves as expected.