<div dir="ltr">When there is too high strata, ntpdate can understand this and always write this into its log. In our case there are just no log - ntpdate send first packet, get an answer - that's all. So, fudging won't save us, as I think. Also, it's a really bad approach to fudge a server which doesn't have a real clock onboard.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 26, 2016 at 10:41 PM, Alex Schultz <span dir="ltr"><<a href="mailto:aschultz@mirantis.com" target="_blank">aschultz@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jan 26, 2016 at 11:42 AM, Stanislaw Bogatkin<br>
<<a href="mailto:sbogatkin@mirantis.com">sbogatkin@mirantis.com</a>> wrote:<br>
> Hi guys,<br>
><br>
> for some time we have a bug [0] with ntpdate. It doesn't reproduced 100% of<br>
> time, but breaks our BVT and swarm tests. There is no exact point where<br>
> problem root located. To better understand this, some verbosity to ntpdate<br>
> output was added but in logs we can see only that packet exchange between<br>
> ntpdate and server was started and was never completed.<br>
><br>
<br>
</span>So when I've hit this in my local environments there is usually one or<br>
two possible causes for this. 1) lack of network connectivity so ntp<br>
server never responds or 2) the stratum is too high.  My assumption is<br>
that we're running into #2 because of our revert-resume in testing.<br>
When we resume, the ntp server on the master may take a while to<br>
become stable. This sync in the deployment uses the fuel master for<br>
synchronization so if the stratum is too high, it will fail with this<br>
lovely useless error.  My assumption on what is happening is that<br>
because we aren't using a set of internal ntp servers but rather<br>
relying on the standard <a href="http://ntp.org" rel="noreferrer" target="_blank">ntp.org</a> pools.  So when the master is being<br>
resumed it's struggling to find a good enough set of servers so it<br>
takes a while to sync. This then causes these deployment tasks to fail<br>
because the master has not yet stabilized (might also be geolocation<br>
related).  We could either address this by fudging the stratum on the<br>
master server in the configs or possibly introducing our own more<br>
stable local ntp servers. I have a feeling fudging the stratum might<br>
be better when we only use the master in our ntp configuration.<br>
<span class=""><br>
> As this bug is blocker, I propose to merge [1] to better understanding<br>
> what's going on. I created custom ISO with this patchset and tried to run<br>
> about 10 BVT tests on this ISO. Absolutely with no luck. So, if we will<br>
> merge this, we would catch the problem much faster and understand root<br>
> cause.<br>
><br>
<br>
</span>I think we should merge the increased logging patch anyway because<br>
it'll be useful in troubleshooting but we also might want to look into<br>
getting an ntp peers list added into the snapshot.<br>
<span class=""><br>
> I appreciate your answers, folks.<br>
><br>
><br>
> [0] <a href="https://bugs.launchpad.net/fuel/+bug/1533082" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1533082</a><br>
> [1] <a href="https://review.openstack.org/#/c/271219/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/271219/</a><br>
> --<br>
> with best regards,<br>
> Stan.<br>
><br>
<br>
</span>Thanks,<br>
-Alex<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>with best regards,</div><div>Stan.</div></div></div></div></div>
</div>