[Yahoo-eng-team] [Bug 1539387] [NEW] l2 agent should subscribe to dvr_update topic only when dvr is enabled
Public bug reported: In OVS Neutron agent, I see that the dvr_update topic is being added to the consumer list irrespective of DVR being enabled or not. Because of this, even though I have disabled DVR in my environment, I still see the agent subscribe and listen on dvr_update topic. It is expected that the agent subscribes to dvr_update only when dvr is enabled in the environment. ** Affects: neutron Importance: Undecided Status: New ** Tags: l3-dvr-backlog -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1539387 Title: l2 agent should subscribe to dvr_update topic only when dvr is enabled Status in neutron: New Bug description: In OVS Neutron agent, I see that the dvr_update topic is being added to the consumer list irrespective of DVR being enabled or not. Because of this, even though I have disabled DVR in my environment, I still see the agent subscribe and listen on dvr_update topic. It is expected that the agent subscribes to dvr_update only when dvr is enabled in the environment. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1539387/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1495592] [NEW] In DHCP agent, resync only for the required networks when sync_state fails
Public bug reported: In sync_state method of DHCP agent, if we are trying to resync one failed network, and then an exception occurs, say for get_active_networks_info, we try to resync all the networks, which is not desired. ** Affects: neutron Importance: Undecided Assignee: Sudhakar Gariganti (sudhakar-gariganti) Status: New ** Tags: l3-ipam-dhcp ** Changed in: neutron Assignee: (unassigned) => Sudhakar Gariganti (sudhakar-gariganti) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1495592 Title: In DHCP agent, resync only for the required networks when sync_state fails Status in neutron: New Bug description: In sync_state method of DHCP agent, if we are trying to resync one failed network, and then an exception occurs, say for get_active_networks_info, we try to resync all the networks, which is not desired. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1495592/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1495628] [NEW] In DHCP agent's enable_dhcp_helper, its good to call safe_configure_dhcp_for_network
Public bug reported:
def enable_dhcp_helper(self, network_id):
"""Enable DHCP for a network that meets enabling criteria."""
network = self.safe_get_network_info(network_id)
if network:
self.configure_dhcp_for_network(network)
Its quite possible that we can get exceptions in
configure_dhcp_for_network and its better to call its safer counterpart,
which takes care of handling any exceptions.
** Affects: neutron
Importance: Undecided
Assignee: Sudhakar Gariganti (sudhakar-gariganti)
Status: In Progress
** Tags: l3-ipam-dhcp
** Changed in: neutron
Assignee: (unassigned) => Sudhakar Gariganti (sudhakar-gariganti)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1495628
Title:
In DHCP agent's enable_dhcp_helper, its good to call
safe_configure_dhcp_for_network
Status in neutron:
In Progress
Bug description:
def enable_dhcp_helper(self, network_id):
"""Enable DHCP for a network that meets enabling criteria."""
network = self.safe_get_network_info(network_id)
if network:
self.configure_dhcp_for_network(network)
Its quite possible that we can get exceptions in
configure_dhcp_for_network and its better to call its safer
counterpart, which takes care of handling any exceptions.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1495628/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1494682] [NEW] l3 agent avoid unnecessary full_sync
Public bug reported: In _process_router_update method, we set full_sync to true a couple of places which can be avoided. There is even a TODO from Carl saying so. # TODO(Carl) Stop this fullsync non-sense. Just retry this # one router by sticking the update at the end of the queue # at a lower priority. ** Affects: neutron Importance: Undecided Status: New ** Tags: l3-dvr-backlog -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1494682 Title: l3 agent avoid unnecessary full_sync Status in neutron: New Bug description: In _process_router_update method, we set full_sync to true a couple of places which can be avoided. There is even a TODO from Carl saying so. # TODO(Carl) Stop this fullsync non-sense. Just retry this # one router by sticking the update at the end of the queue # at a lower priority. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1494682/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1490308] [NEW] In DHCP agent's sync_state, get_active_networks_info RPC times out, when there are large number of networks.
Public bug reported: In our scale tests, for the scenario of supporting large number of networks, we encountered frequent RPC timeouts for the get_active_networks_info call in the sync_state method. Once this timeout happens, it takes an indefinite amount of time for the DHCP agent to recover as it keeps doing alot of redundant work. Assume I am at provisioning some 600th tenant network and fail to enable the DHCP for that network. So a resync is scheduled for this network alone. Now in the sync_state method, we fire get_active_networks_info call, which doesn't have any 'filters'. Neutron server takes its own sweet time to return as it had to, 1. fetch all networks from DB which are hosted on this agent and try to schedule 2. fetch subnets info for all networks , 3. fetch ports info for all networks, By the time the response comes, agent had already timed out the default 60sec timeout. Though the step 1 makes sense for some cases, we don't need to get subnet and ports info for all the networks, when we actually want to resync only 1 network. I think we need to resurrect the get_active_networks RPC and have filtering in get_active_networks_info RPC. P.S: Increasing the rpc_timeout is definetly an option, but given the possible room of improvement in agent code, I do not want to call that shot already. ** Affects: neutron Importance: Undecided Assignee: Sudhakar Gariganti (sudhakar-gariganti) Status: New ** Tags: l3-ipam-dhcp ** Changed in: neutron Assignee: (unassigned) = Sudhakar Gariganti (sudhakar-gariganti) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1490308 Title: In DHCP agent's sync_state, get_active_networks_info RPC times out, when there are large number of networks. Status in neutron: New Bug description: In our scale tests, for the scenario of supporting large number of networks, we encountered frequent RPC timeouts for the get_active_networks_info call in the sync_state method. Once this timeout happens, it takes an indefinite amount of time for the DHCP agent to recover as it keeps doing alot of redundant work. Assume I am at provisioning some 600th tenant network and fail to enable the DHCP for that network. So a resync is scheduled for this network alone. Now in the sync_state method, we fire get_active_networks_info call, which doesn't have any 'filters'. Neutron server takes its own sweet time to return as it had to, 1. fetch all networks from DB which are hosted on this agent and try to schedule 2. fetch subnets info for all networks , 3. fetch ports info for all networks, By the time the response comes, agent had already timed out the default 60sec timeout. Though the step 1 makes sense for some cases, we don't need to get subnet and ports info for all the networks, when we actually want to resync only 1 network. I think we need to resurrect the get_active_networks RPC and have filtering in get_active_networks_info RPC. P.S: Increasing the rpc_timeout is definetly an option, but given the possible room of improvement in agent code, I do not want to call that shot already. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1490308/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1482554] [NEW] skip setting up firewall filters for ports not attached to any security groups
Public bug reported: Not all neutron ports have security groups attached to them. In OVS Neutron agent, when we try to process a newly discovered port (be it a compute or network), we get the port details from the server and then try to apply the firewall filters. But typically for network (DHCP and L3) ports, we do not have any security groups associated. We can actually skip the setup_port_filters for these ports, which can help us save RPC bandwidth and server processing time. In scaled environments, any resync in L2 agent which is serving huge number of DHCP ports, is taking longer time because of this unnecessary workflow. Same thing applies to agent restart scenario as well. ** Affects: neutron Importance: Undecided Assignee: Sudhakar Gariganti (sudhakar-gariganti) Status: New ** Tags: ml2 securitygroups ** Changed in: neutron Assignee: (unassigned) = Sudhakar Gariganti (sudhakar-gariganti) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1482554 Title: skip setting up firewall filters for ports not attached to any security groups Status in neutron: New Bug description: Not all neutron ports have security groups attached to them. In OVS Neutron agent, when we try to process a newly discovered port (be it a compute or network), we get the port details from the server and then try to apply the firewall filters. But typically for network (DHCP and L3) ports, we do not have any security groups associated. We can actually skip the setup_port_filters for these ports, which can help us save RPC bandwidth and server processing time. In scaled environments, any resync in L2 agent which is serving huge number of DHCP ports, is taking longer time because of this unnecessary workflow. Same thing applies to agent restart scenario as well. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1482554/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1386643] [NEW] report_state thread should be started only after the ovs agent initialization is finished
Public bug reported: In OpenvSwitch agent, report_state thread is initiated from setup_rpc method. setup_rpc is just the beginning of agent initialization and followed by bridge configurations. So, report states should be started after all the configuration is done. If the agent dies due to any issues in the bridge configuration steps, there is no point having sent a report_state with start_flag, where the agent has actually not started/initialized properly. ** Affects: neutron Importance: Undecided Assignee: Sudhakar Gariganti (sudhakar-gariganti) Status: New ** Tags: ovs ** Changed in: neutron Assignee: (unassigned) = Sudhakar Gariganti (sudhakar-gariganti) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1386643 Title: report_state thread should be started only after the ovs agent initialization is finished Status in OpenStack Neutron (virtual network service): New Bug description: In OpenvSwitch agent, report_state thread is initiated from setup_rpc method. setup_rpc is just the beginning of agent initialization and followed by bridge configurations. So, report states should be started after all the configuration is done. If the agent dies due to any issues in the bridge configuration steps, there is no point having sent a report_state with start_flag, where the agent has actually not started/initialized properly. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1386643/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
