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 <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Andrew Mirantis Ceph community _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
