) dhcp_device_manager
default:
"neutron.agent.linux.dhcp.DeviceManager"
5) notifies_port_ready
default: True
** Affects: neutron
Importance: Undecided
Assignee: Ramu Ramamurthy (ramu-ramamurthy)
Status: New
** Changed in: neutron
Assignee: (unassigned) => Ramu Ramamurth
Public bug reported:
We need the ability to change the debug levels on the fly on neutron
components (neutron-server, agents) to debug problems as they are
happening.
Currently, changing log level requires a service restart (after changing
the log level in the config file). Changing debug-level
Public bug reported:
Problem
--
Debugging common networking/neutron problems (1. cannot ping VM, 2. cannot ping
FIP),
tends to be manual, and requires root access to look into the state of the
agents or the datapath
on different hosts.
Neutron needs to provide a "diagnostics"
to ideally be an oslo project - as it can be
used by all
openstack projects, but it can be proved in neutron first.
** Affects: neutron
Importance: Undecided
Assignee: Ramu Ramamurthy (ramu-ramamurthy)
Status: New
** Tags: rfe
** Description changed:
As per the comment above, I will close this as fix-released (the patch noted
above)
and create a RFE bug to track further improvements needed.
I will also create a RFE bug to provide an option to run neutron agents
in a "profiled" mode.
** Changed in: neutron
Status: Triaged => Fix
Public bug reported:
Please refer to the comments in the following bug:
https://bugs.launchpad.net/neutron/+bug/1492456
In which it was suggested to handle improving SG programming performance
as a RFE bug.
To Summarize the problem, when there are about 160 VMs, the neutron-ovs-
agent takes
s: neutron
Importance: Undecided
Assignee: Ramu Ramamurthy (ramu-ramamurthy)
Status: New
** Tags: rfe
** Tags added: rfe
** Changed in: neutron
Assignee: (unassigned) => Ramu Ramamurthy (ramu-ramamurthy)
--
You received this bug notification because you are a member of Yahoo
Public bug reported:
I am running Kilo 2015.1.0, with neutron-OVS, and iptables firewall.
I run into situations, where, the iptables SG chains/rules are
inconsistent with ovs-ports, and system interfaces - see below for an
example. In these situations, when I restart neutron-ovs-agent, I expect
Public bug reported:
I used cProfile to profile neutron-ovs-agent (from neutron kilo
2015.1.0) as VMs are provisioned (see code sample below to reproduce).
I find a couple of functions in the IptablesManager scaling poorly with # of
VMs (_modify_rules, and its callee find_last_entry).
As the #
I applied the following patch released in the later kilo release
(neutron/2015.1.1)
- [81e043f] Don't delete port from bridge on delete_port event
https://bugs.launchpad.net/neutron/+bug/165
and the problem is not seen anymore.
** Changed in: neutron
Status: New => Fix Released
--
Public bug reported:
Summary: 40 VMs are created and then deleted on the same host. At the end of
this, I find that iptables rules for some ports are not cleaned up, and remain
as garbage. This garbage keeps piling up, as more VMs are created and deleted.
Topology:
Public bug reported:
Scenario:
VM port with 1 Security Group with 1 egress icmp rule
(example rule:
{u'ethertype': u'IPv4', u'direction': u'egress', u'protocol': u'icmp',
u'dest_ip_prefix': u'0.0.0.0/0'}
)
Steps:
Delete the (last) rule from the above Security Group via Horizon
Marking this as invalid because, a solution to the problem exists - and
as such it is not a code bug.
** Changed in: neutron
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
Public bug reported:
Scenario:
MultiNic VM -eth0 (192.168.100.44)
-eth1 (192.168.0.10)
-eth2 (192.168.20.10)
Test:
Ping 192.168.0.10 does not work
Ping 192.168.100.44 works
RootCause:
default route on
14 matches
Mail list logo
