Thanks, Matt & Andrey. Adding Gleg & Greg to say if they are satisfied with the proposed bug resolution.
Roman On Thu, Jan 23, 2014 at 8:48 AM, Matthew Mosesohn <[email protected]>wrote: > 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 <[email protected]> > wrote: > > > > > > > > On Thu, Jan 23, 2014 at 8:16 PM, Matthew Mosesohn < > [email protected]> > > 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 : [email protected] > >> Unsubscribe : https://launchpad.net/~fuel-dev > >> More help : https://help.launchpad.net/ListHelp > > > > > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
