-
Notifications
You must be signed in to change notification settings - Fork 186
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
Optimize deployment setup time #795
base: develop
Are you sure you want to change the base?
Conversation
@@ -75,16 +75,3 @@ | |||
retries: "{{ shc_sync_retry_num }}" | |||
delay: "{{ retry_delay }}" | |||
no_log: "{{ hide_password }}" | |||
|
|||
- name: Destructive sync search head |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we instead make it optional? would it cause any issues while performing upgrades?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is one of those tasks that took almost 5 minutes to complete. According to this doc https://docs.splunk.com/Documentation/Splunk/9.2.0/DistSearch/HowconfrepoworksinSHC#Why_a_recovering_member_might_need_to_resync_manually we shouldn't need to perform a destructive sync unless the cluster is recovering a member, and then it's only necessary on that one instance. We always could leave this off by default and have some flag to run it if possible.
- include_tasks: set_certificate_prefix.yml | ||
when: splunk.splunk_http_enabled|bool == true | ||
|
||
- include_tasks: clean_user_seed.yml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to remove this playbook from the repository? it's not used anywhere else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don'r recall exactly, but I think the user seed is used to determine if this is the first time Splunk is bootstrapped or not. I remember running into a problem when doing upgrade and when using local dev build because of it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this one I don't have strong preferences about, I couldn't find anything in the docs about what happens if we keep this around.
@@ -122,14 +122,9 @@ | |||
- include_tasks: enable_dsp.yml | |||
when: "'dsp' in splunk and 'enable' in splunk.dsp and splunk.dsp.enable" | |||
|
|||
- include_tasks: start_splunk.yml | |||
|
|||
- include_tasks: set_certificate_prefix.yml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also this playbook?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This playbook, set_certificate_prefix I essentially incorporated into roles/splunk_common/tasks/enable_splunkd_ssl.yml. If we turn on ssl we might as well set the certificate prefix in the same file instead of having two different steps.
Removed multiple restarts that were slowing down deployment setup as well as other tasks that are no longer recommended per Splunk Docs.