Yes, it does.
On Sat, Nov 15, 2014 at 3:15 AM, Rick Jones wrote:
> On 11/14/2014 04:01 PM, Dmitry Borodaenko wrote:
>
>> If NTP server is not reachable on the first boot of the master node,
>> it should be disabled by bootstrap_admin_node, that eliminates the
>> possibility of it spontaneously c
On 11/14/2014 04:01 PM, Dmitry Borodaenko wrote:
If NTP server is not reachable on the first boot of the master node,
it should be disabled by bootstrap_admin_node, that eliminates the
possibility of it spontaneously coming to life and changing the clock
for fuel master node and all target nodes
If NTP server is not reachable on the first boot of the master node,
it should be disabled by bootstrap_admin_node, that eliminates the
possibility of it spontaneously coming to life and changing the clock
for fuel master node and all target nodes in the middle of a
deployment. Then all Nailgun nee
Andrew,
That just shifts the error into Nailgun which is forced to examine NTP
settings of the host. With docker containerization, it makes detecting
this much more difficult. Erroring during fuelmenu is the only chance
where a user can effectively set the NTP parameters correctly. We
could write a
Should we just block the deployment until the NTP is fixed so they
know they need to fix it?
On Wed, Nov 12, 2014 at 6:06 PM, Stanislaw Bogatkin
wrote:
> Hi all,
> Today we have a next workflow about NTP in Fuel:
>
> 1. When someone deploy a master node, we need to somehow operate with NTP
> and
Hi all,
Today we have a next workflow about NTP in Fuel:
1. When someone deploy a master node, we need to somehow operate with NTP
and set upstream NTP servers to Fuel NTP daemon on master node.
2. NTP will enabled by default and set to default upstream values (from
ntp.org pool).
3. If user will
