Thanks, I have got a patchset out for review.
I have removed the exception that was being thrown back to the agent and
have reduced the fix to just logging a meaningful message in the neutron
server logs.
Appreciate your comments on the same.
Thanks,
Sudipto
On Monday 13 April 2015 11:56 AM, Kevin Benton wrote:
I would like to see some form of this merged at least as an error
message. If a server has a bad CMOS battery and suffers a power
outage, it's clock could easily be several years behind. In that
scenario, the NTP daemon could refuse to sync due to a sanity check.
On Wed, Apr 8, 2015 at 10:46 AM, Sudipto Biswas
<sbisw...@linux.vnet.ibm.com <mailto:sbisw...@linux.vnet.ibm.com>> wrote:
Hi Guys, I'd really appreciate your feedback on this.
Thanks,
Sudipto
On Monday 30 March 2015 12:11 PM, Sudipto Biswas wrote:
Someone from my team had installed the OS on baremetal with a
wrong 'date'
When this node was added to the Openstack controller, the logs
from the
neutron-agent on the compute node showed - "AMQP connected".
But the neutron
agent-list command would not list this agent at all.
I could figure out the problem when the neutron-server debug
logs were enabled
and it vaguely pointed at the rejection of AMQP connections
due to a timestamp
miss match. The neutron-server was treating these requests as
stale due to the
timestamp of the node being behind the neutron-server.
However, there's no
good way to detect this if the agent runs on a node which is
ahead of time.
I recently raised a bug here:
https://bugs.launchpad.net/neutron/+bug/1432582
And tried to resolve this with the review:
https://review.openstack.org/#/c/165539/
It went through quite a few +2s after 15 odd patch sets but we
still are not
in common ground w.r.t addressing this situation.
My fix tries to log better and throw up an exception to the
neutron agent on
FIRST time boot of the agent for better detection of the problem.
I would like to get your thoughts on this fix. Whether this
seems legit to have
the fix per the patch OR could you suggest a approach to
tackle this OR suggest
just abandoning the change.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
