I don't think there is any change in Neutron code that can be done to
avoid logging such messages.
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/13
** Changed in: neutron
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1314189
Title:
instance creation fails on compute nodes with > 175 instances
To manage notifi
This bug is in progress: https://review.openstack.org/#/c/85189/
launchpad seem not be willing to update status
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1284718
Title:
interface-attach to exte
** Changed in: nova
Assignee: (unassigned) => Salvatore Orlando (salvatore-orlando)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1284718
Title:
interface-attach to external network a) wo
The bug is still hitting stable builds. Backport is possible, but we
should solve first the related guestfs issues (bug 1275267)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1273386
Title:
Neutron
Crash dumps from test machine.
** Attachment added: "crash_dumps.log"
https://bugs.launchpad.net/neutron/+bug/1273386/+attachment/3963600/+files/crash_dumps.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpa
The kernel bug manifests when mounting of nbd devices is combined with ip
namespace operations.
Using openstack it can be reproduced only with the following configuration:
- compute service must run on the same node as the dhcp-agent and/or the
l3-agent
- file injection should be turned on: libvi
Stefan, regarding comment #12
A few of us have noticed that recent changes in the testing framework
are causing neutron network resources to not be deleted (I filed bug
1274410 this morning, but we have known about this for almost a week
unfortunately).
A side effect is that this leaves a rather
Sorry I was blind.
Kernel crash even with 3.11, same trace.
http://paste.openstack.org/show/62152/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1273386
Title:
Neutron namespace metadata proxy trig
It looks like the OVS and DNS failures were due to nodes not properly built and
these issues were resolved.
However, experimental jobs seem to be revealing "Timed out waiting to get to
ACTIVE" errors without any kernel crash dump.
The error is still what appears to be a hang while mounting the n
of course I did not mean "the new kernel is also unable to resolve the
hostname". the comment was referred to the node, not the kernel
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1273386
Title:
Ne
We have now rolled the new kernel in the nodes used for the experimental jobs.
This did not help anyway. In the logs the 'waiting for thing to become ACTIVE'
failures are still present, but there is a different failure mode (no kernel
crash).
However, openvswitch is just not working [1] and the
thanks Chris I will try your kernel asap!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1273386
Title:
Neutron namespace metadata proxy triggers kernel crash on Ubuntu
12.04/3.2 kernel
To manage
forgot to mention that when we dealt with bug 1224001 we were running
3.2.0-54
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1273386
Title:
Neutron namespace metadata proxy triggers kernel crash on
Hi Stefan,
I have a few more info.
I am trying to run the tests which trigger the issue on two machines, one with
3.2.0-57 and the other with 3.2.0-58.
So far, after 20 runs on each machine, the crash did not happen, so I can't yet
confirm the regression.
However, back in october we had another
I've run the related patch twice, and the kernel bug was hit even with
SIGTERM rather than SIGKILL.
I think this kind of confirms that "failure to become ACTIVE" error is
related to issues while terminating metadata proxies and dnsmasq
instances.
--
You received this bug notification because you
More info.
The crash actually happen when a process is killed. This has consistently
happened in 10 failures I've analyzed.
So the first conclusion is that this might be, after all, a red herring, and
the kernel dump being merely a consequence of the abrupt killing of a process.
I've pushed this
I have worked a bit more on this issue, and it seems that the crash
happens when a process is executed in a namespace. So it's not the
metadata proxy doing something that crashes the kernel, but is the act
of launching the metadata proxy which causes the crash.
--
You received this bug notificati
18 matches
Mail list logo
