<div dir="ltr">Hi,<div><br></div><div>Are any chance to configure chrony instead of ntpd? It acts more predictable on virtual environments.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">--<br>
Best regards,<br>
Sergii Golovatiuk,<br>
Skype #golserge<br>
IRC #holser<br></div></div></div>
<br><div class="gmail_quote">On Mon, Sep 21, 2015 at 4:11 PM, Jesse Pretorius <span dir="ltr"><<a href="mailto:jesse.pretorius@gmail.com" target="_blank">jesse.pretorius@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On 18 September 2015 at 14:03, Major Hayden <span dir="ltr"><<a href="mailto:major@mhtx.net" target="_blank">major@mhtx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hey there,<br>
<br>
I start working on a bug[1] last night about adding a managed NTP configuration to openstack-ansible hosts. My patch[2] gets chrony up and running with configurable NTP servers, but I'm still struggling to meet the "Proposal" section of the bug where the author has asked for non-infra physical nodes to get their time from the infra nodes. I can't figure out how to make it work for AIO builds when one physical host is part of all of the groups. ;)<br>
<br>
I'd argue that time synchronization is critical for a few areas:<br>
<br>
1) Security/auditing when comparing logs<br>
2) Troubleshooting when comparing logs<br>
3) I've been told swift is time-sensitive<br>
4) MySQL/Galera don't like time drift<br>
<br>
However, there's a strong argument that this should be done by deployers, and not via openstack-ansible. I'm still *very* new to the project and I'd like to hear some feedback from other folks.<br>
<br>
[1] <a href="https://bugs.launchpad.net/openstack-ansible/+bug/1413018" rel="noreferrer" target="_blank">https://bugs.launchpad.net/openstack-ansible/+bug/1413018</a><br>
[2] <a href="https://review.openstack.org/#/c/225006/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/225006/</a></blockquote><div><br></div></span><div>We have historically taken the stance of leaving something like this as a deployer concern - much like setting up host networking and setting host repositories. That said, there's value in opinionation based on best practices learned from hard-won lessons in the trenches.</div><div><br></div><div>I'm somewhat on the fence with this. As-is I don't think the review should go in. That said, I'd be more open to an individual role being used to implement an appropriate network time configuration - whether that role be something that exists within Ansible Galaxy, or whether it's a new role in the current repository, or as its own repository in the OpenStack-Ansible 'big tent' as proposed in <a href="https://review.openstack.org/213779" target="_blank">https://review.openstack.org/213779</a></div><div><br></div><div>I do definitely think that there's value in preparing some documentation which will help prospective deployers understand how they can consume roles from Ansible Galaxy (or some role in an arbitrary repository) to solve common problems like this. The tooling is already in the OpenStack-Ansible repository, so all it needs is a guiding document which describes how to use it.</div></div>
</div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>