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 <mmoses...@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 <xar...@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 >> <sbogat...@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@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> -- >> Andrew >> Mirantis >> Ceph community >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Dmitry Borodaenko _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev