fuel-dev team mailing list archive

[Matthew Mosesohn <mmosesohn@xxxxxxxxxxxx>]

Fuel node will run NTP, but its only source of truth is its own hardware clock.

A time check task sounds great. Honestly, this should be provided by a
monitoring tool and we shouldn't rewrite it by ourselves.

One way to keep drift down is to turn controllers into NTP time
sources for ceph and computes, and then the controllers sync against
external source with force resync disabled.



On Thu, Jan 23, 2014 at 8:38 PM, Andrey Korolev <akorolev@xxxxxxxxxxxx> wrote:
>
>
>
> On Thu, Jan 23, 2014 at 8:16 PM, Matthew Mosesohn <mmosesohn@xxxxxxxxxxxx>
> wrote:
>>
>> Hi all,
>>
>> I'm discussing the following bug and code review for a wider audience:
>> https://bugs.launchpad.net/fuel/+bug/1263934
>> https://review.openstack.org/#/c/68670/
>>
>> I value appreciate your feedback and suggestions for how to improve
>> the user experience.
>>
>> In the first iteration of Fuel Menu, there was no NTP, but just DNS
>> settings. A user can set an upstream DNS server that fails to connect
>> in Fuel Menu, but if there are problems, it will show a warning to the
>> user when trying to save (but still saves). If you make the DNS server
>> empty, it will also warn with a slightly more friendly warning.
>>
>> With NTP, in this patch I've added an "Enable NTP" option. Before, you
>> had to remove all 3 server entries in order to suppress the error that
>> blocks saving. Displaying multiple sequential warnings in Fuel Menu
>> isn't very appealing to users, so I opted for one automatic decision
>> to be made: disable NTP automatically if there is no gateway. It's
>> easy to detect, and it's very unlikely to be able to reach an NTP
>> server without a gateway. Therefore, it should just be disabled by
>> default.
>>
> Does this means that the Fuel node will not launch an NTP service at all? We
> are still in need to synchronize time on the Openstack nodes even if time
> source is known to be wrong. All I can suggest as a further improvement is
> to detect clock drift change on the OS nodes and to inject shift at once by
> an orchestrator if it is too large for ntpd to chew. Unfortunately we`re
> still on dark side with galera because it can broke at once if user will
> update master node NTP config somehow so large delay will be passed
> through(tens of seconds) in a non-simultaneous manner. So as soon as we will
> switch to the more reliable replication mechanism for database which can
> survive one-minute clock adjust on a short interval no other service states
> will be broken(except health warning for ceph, which actually equals to the
> frozen I/O during adjust window).
>
>>
>> That having been said, this means we're defaulting Fuel install to not
>> use a 3rd party NTP source and not pushing our users to set up an
>> Internet connection for the Fuel node.
>>
>> What are your thoughts? How else should this be architected?
>>
>> Best Regards,
>> Matthew Mosesohn
>>
>> --
>> Mailing list: https://launchpad.net/~fuel-dev
>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~fuel-dev
>> More help   : https://help.launchpad.net/ListHelp
>
>