A few observation about neutron failures.
3 distinct failure modes have been observed. they all related to the fact that we've completely turned off injection and are now relying on metadata, which is course not working as well as it should.(*)
Failure mode 1 -> q-meta crashes at startup: http://logs.openstack.org/92/69792/10/check/check-tempest-dsvm-neutron-isolated/82e1716/logs/screen-q-meta.txt.gz It seems a rather easy fix. Failure mode 2 -> failure in nova api while retrieving metadata: http://logs.openstack.org/78/70178/5/check/check-tempest-dsvm-neutron-isolated/f65aaa8/logs/screen-n-api.txt.gz#_2014-02-05_16_22_12_713 This needs some investigation and appears to be the most common failure mode Failure mode 3 -> q-vpn crashes at startup. Not yet sure why the lbaas agent is called into play
I will also add instance console logging to the load balancing scenario to verify whether there is an additional failure mode.
(*) Personally I was expecting this
A few observation about neutron failures.
3 distinct failure modes have been observed. they all related to the fact that we've completely turned off injection and are now relying on metadata, which is course not working as well as it should.(*)
Failure mode 1 -> q-meta crashes at startup: http:// logs.openstack. org/92/ 69792/10/ check/check- tempest- dsvm-neutron- isolated/ 82e1716/ logs/screen- q-meta. txt.gz logs.openstack. org/78/ 70178/5/ check/check- tempest- dsvm-neutron- isolated/ f65aaa8/ logs/screen- n-api.txt. gz#_2014- 02-05_16_ 22_12_713
It seems a rather easy fix.
Failure mode 2 -> failure in nova api while retrieving metadata: http://
This needs some investigation and appears to be the most common failure mode
Failure mode 3 -> q-vpn crashes at startup. Not yet sure why the lbaas agent is called into play
I will also add instance console logging to the load balancing scenario to verify whether there is an additional failure mode.
(*) Personally I was expecting this