fuel-dev team mailing list archive

[Roman Alekseenkov <ralekseenkov@xxxxxxxxxxxx>]

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 <mmosesohn@xxxxxxxxxxxx>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 <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
> >
> >
>
> --
> 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
>