[openstack-dev] [Neutron] Regarding neutron bug # 1432582

Sudipto Biswas sbiswas7 at linux.vnet.ibm.com
Mon Apr 13 18:33:16 UTC 2015


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 
> <sbiswas7 at linux.vnet.ibm.com <mailto:sbiswas7 at 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-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list