<?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 Deployment server - live class status in Deployment Architecture</title>
    <link>https://community.splunk.com/t5/Deployment-Architecture/Deployment-server-live-class-status/m-p/117666#M4445</link>
    <description>&lt;P&gt;I'm watching the status for a given deployment class (Manager » Deployment » Deployment server » Class Status) in real time (or near real time by reloading the page every couple of seconds), and I am seeing puzzling behaviour.  After changing the serverclass.conf and reloading the deployment server I would expect to see the numbers start at zero and increment as the end-points check in, and then given a static estate and a static configuration I would expect that number to remain stable once all machines had updated their config.  What I am actually seeing is the number in the list fluctuates down as well as up (+/- about 10 machines in a total estate of 106), despite the fact the end points themselves have no changes to download.  I'm not sure that the list is ever complete or definitive.&lt;/P&gt;

&lt;P&gt;Could someone with in-depth knowledge please re-assure me that this is not indicative of unstable behaviour.  (Currently running Splunk 5.0.5 for the deployment server, and 5.0.5 or 4.3.2 for the end points.)&lt;/P&gt;</description>
    <pubDate>Tue, 24 Jun 2014 14:36:43 GMT</pubDate>
    <dc:creator>grijhwani</dc:creator>
    <dc:date>2014-06-24T14:36:43Z</dc:date>
    <item>
      <title>Deployment server - live class status</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Deployment-server-live-class-status/m-p/117666#M4445</link>
      <description>&lt;P&gt;I'm watching the status for a given deployment class (Manager » Deployment » Deployment server » Class Status) in real time (or near real time by reloading the page every couple of seconds), and I am seeing puzzling behaviour.  After changing the serverclass.conf and reloading the deployment server I would expect to see the numbers start at zero and increment as the end-points check in, and then given a static estate and a static configuration I would expect that number to remain stable once all machines had updated their config.  What I am actually seeing is the number in the list fluctuates down as well as up (+/- about 10 machines in a total estate of 106), despite the fact the end points themselves have no changes to download.  I'm not sure that the list is ever complete or definitive.&lt;/P&gt;

&lt;P&gt;Could someone with in-depth knowledge please re-assure me that this is not indicative of unstable behaviour.  (Currently running Splunk 5.0.5 for the deployment server, and 5.0.5 or 4.3.2 for the end points.)&lt;/P&gt;</description>
      <pubDate>Tue, 24 Jun 2014 14:36:43 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Deployment-server-live-class-status/m-p/117666#M4445</guid>
      <dc:creator>grijhwani</dc:creator>
      <dc:date>2014-06-24T14:36:43Z</dc:date>
    </item>
    <item>
      <title>Re: Deployment server - live class status</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Deployment-server-live-class-status/m-p/117667#M4446</link>
      <description>&lt;P&gt;Pre 6.x, I believe that the class status is computed based on a fixed time range (like 10 minutes). I don't think the numbers are reset when the deployment server is reloaded.&lt;/P&gt;

&lt;P&gt;If you want to understand exactly what is happening with your deployment server, I would examine the Splunk logs in the &lt;CODE&gt;_internal&lt;/CODE&gt; index. Here are a few searches that could provide a starting point:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;index=_internal component=deployedapplication OR component=deploymentclient
| sort host _time 
| table host _time component message

index=_internal sourcetype=splunkd component=Metrics group=ds_connections* |
rename ip as deploymentClient mgmt as mgmtPort |
fields deploymentClient mgmtPort utsname dsevent |
table _time deploymentClient mgmtPort utsname dsevent 

index=_internal component=deploymentclient phonehome 
| sort host _time 
| table host _time component message
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;(Note that the internal log file format changed somewhat between 5.x and 6x, so you may have to tweak the search to get exactly what you want.)&lt;/P&gt;</description>
      <pubDate>Tue, 24 Jun 2014 21:40:39 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Deployment-server-live-class-status/m-p/117667#M4446</guid>
      <dc:creator>lguinn2</dc:creator>
      <dc:date>2014-06-24T21:40:39Z</dc:date>
    </item>
    <item>
      <title>Re: Deployment server - live class status</title>
      <link>https://community.splunk.com/t5/Deployment-Architecture/Deployment-server-live-class-status/m-p/117668#M4447</link>
      <description>&lt;P&gt;On one point I can be definite.  A deployment server reload undoubtedly clear's the tables completely.  Looking at the deployment status of any given class on the GUI or watching a repeated loop of the general deployment status from the command line will demonstrate this.&lt;/P&gt;

&lt;P&gt;But it never occurred to me - until I actually experienced it today that the deployment status of a server might be registered only for a fixed window.  I rather expected it would remain static (all other things being equal), until some material change triggered a redeployment.&lt;/P&gt;

&lt;P&gt;Thanks for the sample queries.&lt;/P&gt;</description>
      <pubDate>Tue, 24 Jun 2014 22:16:12 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Deployment-Architecture/Deployment-server-live-class-status/m-p/117668#M4447</guid>
      <dc:creator>grijhwani</dc:creator>
      <dc:date>2014-06-24T22:16:12Z</dc:date>
    </item>
  </channel>
</rss>

