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

saved_searches only works for new resource creation #127

Open
elvis-cai opened this issue Jun 2, 2022 · 3 comments
Open

saved_searches only works for new resource creation #127

elvis-cai opened this issue Jun 2, 2022 · 3 comments

Comments

@elvis-cai
Copy link

terraform version: 0.15.0
provider version: 1.4.13
we are using terraform to create alert in Splunk cloud, and
https://registry.terraform.io/providers/splunk/splunk/latest/docs/resources/saved_searches this resource only works to create new alerts, when changing existing ones, it didn't work.
the video replay would be here https://drive.google.com/file/d/1Qb0bW6pSZT5FmFe_dNdpO9TIarSthUO5/view?usp=sharing

@yuriyonamine
Copy link

We have a similar issue related to permissions. The changes are applied only if the Splunk user has the "admin_all_objects" capability.
I believe it should allow us to update the alerts without that capability since the user is the owner and it can be done via API or UI.

@rajeshgpai
Copy link

We're observing the same with splunk_data_ui_views. New resource are created, but existing ones do not get updated.

I've tried @yuriyonamine's suggestion to add admin_all_objects capability, but that doesnt seem to help.

I'm using
Terraform: 1.0.11
Splunk Provider: 1.4.13

I see the following in the tf log which indicates the update maybe getting rejected. -

2022-06-29T11:11:32.814+1000 [DEBUG] splunk_data_ui_views.dashboard: applying the planned Update change
2022-06-29T11:11:32.832+1000 [WARN]  Provider "provider[\"registry.terraform.io/splunk/splunk\"]" produced an unexpected new value for splunk_data_ui_views.dashboard, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .eai_data: was cty.StringVal("<form version=\"1.1\"><label>Dashboard name after modifying</label></form>"), but now cty.StringVal("<form version=\"1.1\"><label>Dashboard name on creation</label></form>")

@seth-carroll
Copy link

We were running into this exact same issue. Our Terraform CI/CD pipelines could create and destroy splunk alerts/dashboards but not update them. I logged into the Splunk Cloud web UI with the same credentials as the pipeline and was able to update the alerts, which seemed to indicate that it was only an issue with the Terraform provider.

In the Splunk Terraform provider versions up to 1.4.19, the pipeline would act like it applied the changes. Starting in 1.4.20+, it threw this error:

Error: 400 Bad Request: {"messages":[{"type":"ERROR","text":"Argument \"auto_summarize.command\" is not supported by this handler."}]}

Through trial and error, I determined that the Splunk TF provider requires the accelerate_search capability regardless if the saved search is accelerated. Adding accelerate_search to the role resolved that error and caused the pipeline to actually apply the changes.

Here is the full list of capabilities that we now use for our Terraform Splunk role:

accelerate_search
delete_messages
edit_local_apps
edit_log_alert_event
edit_own_objects
edit_search_concurrency_scheduled
edit_search_schedule_priority
edit_search_schedule_window
edit_view_html
embed_report
export_results_is_visible
get_metadata
get_typeahead
input_file
list_accelerate_search
list_all_objects
list_inputs
list_metrics_catalog
list_settings
list_workload_pools
output_file
pattern_detect
request_remote_tok
rest_access_server_endpoints
rest_apps_view
rest_properties_get
run_collect
run_custom_command
run_dump
run_mcollect
run_msearch
run_sendalert
schedule_rtsearch
schedule_search
search
select_workload_pools
upload_lookup_files

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants