<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Is the restartSplunkd parameter honored when using Deployment Server and Search Head Pooling? in Deployment Architecture</title>
    <link>https://community.splunk.com/t5/Deployment-Architecture/Is-the-restartSplunkd-parameter-honored-when-using-Deployment/m-p/98041#M3616</link>
    <description>&lt;BLOCKQUOTE&gt;
&lt;P&gt;What is not clear is how the other&lt;BR /&gt;
search heads in the pool detect the&lt;BR /&gt;
change then restart.&lt;/P&gt;
&lt;/BLOCKQUOTE&gt;

&lt;P&gt;Your suspicion is correct -- the other search heads in the pool do &lt;EM&gt;not&lt;/EM&gt; restart, though they &lt;EM&gt;do&lt;/EM&gt; detect updates to the confs.&lt;/P&gt;

&lt;BLOCKQUOTE&gt;
&lt;P&gt;Is this the expected behavior?&lt;/P&gt;
&lt;/BLOCKQUOTE&gt;

&lt;P&gt;Yes, this is expected behavior.&lt;/P&gt;

&lt;BLOCKQUOTE&gt;
&lt;P&gt;If this is the case, then what is the&lt;BR /&gt;
recommended way to automate a restart&lt;BR /&gt;
for members of the pool which are not&lt;BR /&gt;
deployment clients?&lt;/P&gt;
&lt;/BLOCKQUOTE&gt;

&lt;P&gt;Creating a search head pool where one search head acts as a deployment client only really makes sense when pushing apps that do not require restarts.&lt;/P&gt;

&lt;P&gt;If you're using deployment server to push apps that &lt;EM&gt;do&lt;/EM&gt; require restarts, I'd recommend foregoing search head pooling entirely; just make each search head a standalone deployment client.&lt;/P&gt;</description>
    <pubDate>Fri, 28 Oct 2011 16:31:57 GMT</pubDate>
    <dc:creator>ewoo</dc:creator>
    <dc:date>2011-10-28T16:31:57Z</dc:date>
    <item>
      <title>Is the restartSplunkd parameter honored when using Deployment Server and Search Head Pooling?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Is-the-restartSplunkd-parameter-honored-when-using-Deployment/m-p/98040#M3615</link>
      <description>&lt;P&gt;I understand it is possible to use Deployment Server to propagate config changes to a Search Head Pool as documented here: &lt;/P&gt;

&lt;P&gt;&lt;A href="http://docs.splunk.com/Documentation/Splunk/latest/Deploy/Configuresearchheadpooling#Deployment_server_and_search_head_pooling" target="_blank"&gt;http://docs.splunk.com/Documentation/Splunk/latest/Deploy/Configuresearchheadpooling#Deployment_server_and_search_head_pooling&lt;/A&gt;&lt;/P&gt;

&lt;P&gt;It is clear that a single search head can be designated as the deployment client.  It will then sync config to the pool target repository and restart itself.  What is not clear is how the other search heads in the pool detect the change then restart.  When specifying the restartSplunkd parameter in serverclass.conf it does not appear to be honored by search heads which are not designated as deployment clients, but are part of the pool.&lt;/P&gt;

&lt;P&gt;Is this the expected behavior?  It makes sense that it is the expected behavior since the other search heads are not managed by DS.  If this is the case, then what is the recommended way to automate a restart for members of the pool which are not deployment clients?&lt;/P&gt;</description>
      <pubDate>Mon, 28 Sep 2020 10:01:12 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Is-the-restartSplunkd-parameter-honored-when-using-Deployment/m-p/98040#M3615</guid>
      <dc:creator>hulahoop</dc:creator>
      <dc:date>2020-09-28T10:01:12Z</dc:date>
    </item>
    <item>
      <title>Re: Is the restartSplunkd parameter honored when using Deployment Server and Search Head Pooling?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Is-the-restartSplunkd-parameter-honored-when-using-Deployment/m-p/98041#M3616</link>
      <description>&lt;BLOCKQUOTE&gt;
&lt;P&gt;What is not clear is how the other&lt;BR /&gt;
search heads in the pool detect the&lt;BR /&gt;
change then restart.&lt;/P&gt;
&lt;/BLOCKQUOTE&gt;

&lt;P&gt;Your suspicion is correct -- the other search heads in the pool do &lt;EM&gt;not&lt;/EM&gt; restart, though they &lt;EM&gt;do&lt;/EM&gt; detect updates to the confs.&lt;/P&gt;

&lt;BLOCKQUOTE&gt;
&lt;P&gt;Is this the expected behavior?&lt;/P&gt;
&lt;/BLOCKQUOTE&gt;

&lt;P&gt;Yes, this is expected behavior.&lt;/P&gt;

&lt;BLOCKQUOTE&gt;
&lt;P&gt;If this is the case, then what is the&lt;BR /&gt;
recommended way to automate a restart&lt;BR /&gt;
for members of the pool which are not&lt;BR /&gt;
deployment clients?&lt;/P&gt;
&lt;/BLOCKQUOTE&gt;

&lt;P&gt;Creating a search head pool where one search head acts as a deployment client only really makes sense when pushing apps that do not require restarts.&lt;/P&gt;

&lt;P&gt;If you're using deployment server to push apps that &lt;EM&gt;do&lt;/EM&gt; require restarts, I'd recommend foregoing search head pooling entirely; just make each search head a standalone deployment client.&lt;/P&gt;</description>
      <pubDate>Fri, 28 Oct 2011 16:31:57 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Is-the-restartSplunkd-parameter-honored-when-using-Deployment/m-p/98041#M3616</guid>
      <dc:creator>ewoo</dc:creator>
      <dc:date>2011-10-28T16:31:57Z</dc:date>
    </item>
    <item>
      <title>Re: Is the restartSplunkd parameter honored when using Deployment Server and Search Head Pooling?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Is-the-restartSplunkd-parameter-honored-when-using-Deployment/m-p/98042#M3617</link>
      <description>&lt;P&gt;When configuring a deployment client from the CLI, the config (including targetURI) is written to etc/system/local/deploymentclient.conf.  We are trying a solution whereby we delete deploymentclient.conf from etc/system/local and package it as part of a deployment server app. This app is then synced to the SHP target repository by the search head designated as the deployment client.  The effect should be the other search heads in the pool now become implicit deployment clients.  Will report back on whether this worked or not, and if there are any unintended problems.&lt;/P&gt;</description>
      <pubDate>Fri, 28 Oct 2011 16:38:41 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Is-the-restartSplunkd-parameter-honored-when-using-Deployment/m-p/98042#M3617</guid>
      <dc:creator>hulahoop</dc:creator>
      <dc:date>2011-10-28T16:38:41Z</dc:date>
    </item>
    <item>
      <title>Re: Is the restartSplunkd parameter honored when using Deployment Server and Search Head Pooling?</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Is-the-restartSplunkd-parameter-honored-when-using-Deployment/m-p/98043#M3618</link>
      <description>&lt;P&gt;Thank you, ewoo!  We are trying something out which might work, description is posted as an answer.&lt;/P&gt;</description>
      <pubDate>Fri, 28 Oct 2011 16:43:23 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Is-the-restartSplunkd-parameter-honored-when-using-Deployment/m-p/98043#M3618</guid>
      <dc:creator>hulahoop</dc:creator>
      <dc:date>2011-10-28T16:43:23Z</dc:date>
    </item>
  </channel>
</rss>

