Open Stack

Hi Tomasz,
External NTP is good, but we should be able to deploy w/o internet access
(but slaves should be in sync with master node), so sync with master node
is better. I understand that it's slightly against standards - but at that
moment we just obligatoriness to be in sync with master node, cause some of
followed tasks depends on synced time.

On Fri, Dec 19, 2014 at 2:12 PM, Tomasz Napierala <tnapierala at mirantis.com>
wrote:
>
>
> > On 19 Dec 2014, at 10:00, Stanislaw Bogatkin <sbogatkin at mirantis.com>
> wrote:
> >
> > Hi guys,
> >
> > We have a little concern related to Fuel bootstrap node NTP sync.
> Currently we trying to sync time on bootstrap node with master node, but
> problem is that NTP protocol has long convergence time, so if we just
> install master node and right after that try to start some bootstrap node -
> bootstrap fails to sync time with master due to that fact that master
> doesn't appear as "trust time source" at that moment.
> > How we can solve that problem:
> >
> > 1. We can start bootstrap long time after master (when master will
> convergence it's time) - seems that it's a bad idea, cause master node
> convergence time depends on upstream NTP servers and may be quite long -
> user shouldn't wait so long time to just start bootstrap node.
> >
> > 2. We can use master local time as "trust" forcibly - actually, we
> already do that for case when master is a bare metal node. We can do it for
> virtual node too, it is not such bad idea as many can say, especially when
> master node stratum will low (10-12).
> >
> > 3. We can mask return value for bootstrap node ntpdate service such way
> that it always will return success - it's a dirty hack, it will calm down
> customers, but it doesn't solve problem - time will be unsynced.
> >
> > As for me - second option is best. What do you think about it?
>
> Second option looks best, although it’s still against standards. I guess
> that if we provide possibility to deifne external NTP server as an
> alternative, we are hsfa here and can live with that.
>
> Regards,
> --
> Tomasz 'Zen' Napierala
> Sr. OpenStack Engineer
> tnapierala at mirantis.com
>
>
>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141219/3676a9df/attachment.html>