v2.0.0 Introduces bad client config

[EdHurtig]

Client configs are all looking to public servers and not pulling in the private servers

DETAILS

https://travis-ci.org/evertrue/ntp_cluster-cookbook/jobs/167820174

 1) ntp_cluster::default installs /etc/ntp.conf File "/etc/ntp.conf" content should match /^server 46\.22\.26\.12/
            Failure/Error: its(:content) { is_expected.to match(/^server 46\.22\.26\.12/) }
              expected "..." to match /^server 46\.22\.26\.12/
              Diff:
              @@ -1,2 +1,32 @@
              -/^server 46\.22\.26\.12/
              +# Auto-generated by Chef.
              ...
              +server 0.pool.ntp.org iburst minpoll 6 maxpoll 10
              +restrict 0.pool.ntp.org nomodify notrap noquery
              +server 1.pool.ntp.org iburst minpoll 6 maxpoll 10
              +restrict 1.pool.ntp.org nomodify notrap noquery
              +server 2.pool.ntp.org iburst minpoll 6 maxpoll 10
              +restrict 2.pool.ntp.org nomodify notrap noquery
              +server 3.pool.ntp.org iburst minpoll 6 maxpoll 10
              +restrict 3.pool.ntp.org nomodify notrap noquery

REGRESSION

Test passes in v1.1.3 - Travis Build.

• Note FQDNs removed in v2.0.0 in favor of Raw IPs in 86ea93c3ed372c81d6e6a965fabe83176536e0aa. the test also changed, but that does not seem to be the problem here.

+server _default-ntp-1b.priv.evertrue.com iburst minpoll 6 maxpoll 10 prefer
+restrict _default-ntp-1b.priv.evertrue.com nomodify notrap noquery
+server _default-ntp-1c.priv.evertrue.com iburst minpoll 6 maxpoll 10
+restrict _default-ntp-1c.priv.evertrue.com nomodify notrap noquery
+server _default-ntp-1d.priv.evertrue.com iburst minpoll 6 maxpoll 10
+restrict _default-ntp-1d.priv.evertrue.com nomodify notrap noquery

RELATED

Discovered in #10

[EdHurtig]

@eherot While we are on the topic of this cookbook, did you get a chance to look at this issue. / could you run the vagrant test suite which was failing?

[eherot]

I completely refactored this cookbook to break the client recipe out into its own cookbook, which is not (yet) public because it's not a pure application cookbook (though I did grant you permission to look at it).

[eherot]

With the discovery recipe no longer expecting to do both the client and server jobs, it was much easier to fix the above issue.

[EdHurtig]

Allrighty, I'll give it a look over after this... interesting... HyperLoop test week is over

[EdHurtig]

Note: need to look over still

[eherot]

I hope it's not too bad because it's been in production for a few weeks now ;-)

[EdHurtig]

lol yeah, my tests indicated that the client servers were just being configured to look at the public pool so they might end up drifting to 200ms apart from each other which isn't the end of the world but definitely defeats the purpose of a private NTP pool.

[EdHurtig]

Oh and "someone" removed the vagrant kitchen config leaving only the AWS config 👀

grumbles softly

[eherot]

Yeah we've mostly been moving away from Vagrant because testing multiple cookbooks at once using Vagrant tends to crash my laptop. Thankfully Apple will soon be releasing a powerful new MacBook that so I won't have this problem anymore (oh, wait...)

[eherot]

PS. Clients definitely aren't using the public pool. That would indeed be a problem.

[EdHurtig]

Wait, prod clients are currently using the public pool?

I think the command to check is

$ ntpq -p -n

// Some table listing the currently connected clients... should be the NTP Master IP and the slaves ONLY

[eherot]

Nope:

$ sudo ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.0.111.172    128.138.141.172  2 u  815 1024  377    0.532    2.688   0.572
+10.0.112.113    10.0.111.172     3 u  569 1024  377    0.337    1.335   0.454
+10.0.113.249    10.0.111.172     3 u  687 1024  377    0.955    1.947   1.055

[EdHurtig]

Awesome :+1: