Open Stack

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 needs to do is pop a warning notification
that no NTP server is configured on the master node, and it should be
fixed manually before starting any deployments. No need to block
deployment altogether: if the user doesn't need need global time at
all (e.g. in an off-the-grid bunker 2 miles beneath Fort Knox),
synchronizing clocks on all environments just to the Fuel master will
still work.

On Wed, Nov 12, 2014 at 7:28 AM, Matthew Mosesohn
<mmosesohn at mirantis.com> wrote:
> 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 ton of infrastructure around this capability, but all it
> wins us is a more beautiful error that blocks a user from proceeding.
>
> On Wed, Nov 12, 2014 at 7:21 PM, Andrew Woodward <xarses at gmail.com> wrote:
>> 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
>> <sbogatkin at mirantis.com> 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 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 enter to fuelmenu then then he can change that values and it
>>> will stored as new ones.
>>>
>>> That can lead to some errors at deploy, some as:
>>> 1. User set upstream NTP (or use defaults).
>>> 2. By some reasons that NTP servers get unreacheable (i.e. network down).
>>> 3. User creates environment and push 'deploy' button.
>>> 4. In the middle of deploy process upstream NTP become reacheable and master
>>> node sync with them.
>>> If time on master node before that sync will have big shift regarding to
>>> real time, then we will have 2 problems:
>>> 1. Deploy can fail, cause slave nodes will sync with master one time only -
>>> right after provisioning and if master node resync with upstream in the
>>> middle of deploy - some services can stop works (e.g. mcollective).
>>> 3. It will be more complicate to understand logs, cause it will shifted too.
>>>
>>> As I see, we have two ways to solve this:
>>> 1. Check upstream NTP reachability and disable upstream servers if they
>>> unreachable at fuelmenu step. It will cost us some shift with real time in
>>> the end.
>>>
>>>  or
>>>
>>> 2. Disable NTP upstream servers if they unreachable right after user press
>>> 'deploy' button and enable them after deploy is over.
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Andrew
>> Mirantis
>> Ceph community
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Dmitry Borodaenko