[Yahoo-eng-team] [Bug 1281098] [NEW] Too long tunnel devices names
Public bug reported: Openvswitch neutron agent create too long names for tunnel devices. Ports name are created like %type-%remoteip. For example for gre type tunnel, name is gre-192.168.201.10 which exceed max length for linux network devices (15 chars). This name pass throw openvswitch, but create failed port with ofport -1 and proceed with error like this: 2014-02-17 11:25:14.048 22908 ERROR neutron.agent.linux.ovs_lib [-] Unable to execute ['ovs-ofctl', 'add-flow', 'br-tun', 'hard_timeout=0,idle_timeout=0,priority=1,in_port=-1,actions=resubmit(,2)']. Exception: Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ovs-ofctl', 'add-flow', 'br-tun', 'hard_timeout=0,idle_timeout=0,priority=1,in_port=-1,actions=resubmit(,2)'] Exit code: 1 Stdout: '' Stderr: 'ovs-ofctl: -1: negative values not supported for in_port\n' This bug affect only devices with long ip address 10.0.0.1 will pass, but 192.168.201.10 fail. Found in HAVANA with: openvswitch: 1.9.3-1 linux: 3.2.54-2 But I think length limit will apply on all versions. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1281098 Title: Too long tunnel devices names Status in OpenStack Neutron (virtual network service): New Bug description: Openvswitch neutron agent create too long names for tunnel devices. Ports name are created like %type-%remoteip. For example for gre type tunnel, name is gre-192.168.201.10 which exceed max length for linux network devices (15 chars). This name pass throw openvswitch, but create failed port with ofport -1 and proceed with error like this: 2014-02-17 11:25:14.048 22908 ERROR neutron.agent.linux.ovs_lib [-] Unable to execute ['ovs-ofctl', 'add-flow', 'br-tun', 'hard_timeout=0,idle_timeout=0,priority=1,in_port=-1,actions=resubmit(,2)']. Exception: Command: ['sudo', '/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ovs-ofctl', 'add-flow', 'br-tun', 'hard_timeout=0,idle_timeout=0,priority=1,in_port=-1,actions=resubmit(,2)'] Exit code: 1 Stdout: '' Stderr: 'ovs-ofctl: -1: negative values not supported for in_port\n' This bug affect only devices with long ip address 10.0.0.1 will pass, but 192.168.201.10 fail. Found in HAVANA with: openvswitch: 1.9.3-1 linux: 3.2.54-2 But I think length limit will apply on all versions. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1281098/+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 2077009] [NEW] Nova doesn't clean claims after evacuation
Public bug reported: When a VM is evacuated from the failed server without stating explicit destination (i.e. letting the scheduler decide) claims to the old hypervisor in placement are never deleted. How to replicate: - Place VM on the hypervisor - Check that claims are OK: +--++---+--+--+ | resource_provider| generation | resources | project_id | user_id | +--++---+--+--+ | 229cce5f-3b87-438a-baa9-539be0fc9bd8 | 5 | {'VCPU': 1, 'MEMORY_MB': 256} | 4facfb06808a4621b4f47123a0184a4a | 15da82817e56446198fcdd870a45d8f4 | +--++---+--+--+ - Stop the hypervisor and after nova pronounce hypervisor dead run evacuation without stating the destination - Check claims again +--++---+--+--+ | resource_provider| generation | resources | project_id | user_id | +--++---+--+--+ | 229cce5f-3b87-438a-baa9-539be0fc9bd8 | 6 | {'VCPU': 1, 'MEMORY_MB': 256} | 4facfb06808a4621b4f47123a0184a4a | 15da82817e56446198fcdd870a45d8f4 | | 5395932e-b5e0-4a0c-be6a-7328af751642 | 14 | {'VCPU': 1, 'MEMORY_MB': 256} | 4facfb06808a4621b4f47123a0184a4a | 15da82817e56446198fcdd870a45d8f4 | +--++---+--+--+ Result: Claims to the old hypervisor have not been deleted Expected results: Only claims for new hypervisor exist It is possible regression of https://bugs.launchpad.net/nova/+bug/1896463 It probably happened when the resource tracker was improved and the whole migration procedure was rewritten. Migration/resize work because claims deletion happens in confirm/revert action, however, evacuation doesn't have anything like that and so it's never deleted. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2077009 Title: Nova doesn't clean claims after evacuation Status in OpenStack Compute (nova): New Bug description: When a VM is evacuated from the failed server without stating explicit destination (i.e. letting the scheduler decide) claims to the old hypervisor in placement are never deleted. How to replicate: - Place VM on the hypervisor - Check that claims are OK: +--++---+--+--+ | resource_provider| generation | resources | project_id | user_id | +--++---+--+--+ | 229cce5f-3b87-438a-baa9-539be0fc9bd8 | 5 | {'VCPU': 1, 'MEMORY_MB': 256} | 4facfb06808a4621b4f47123a0184a4a | 15da82817e56446198fcdd870a45d8f4 | +--++---+--+--+ - Stop the hypervisor and after nova pronounce hypervisor dead run evacuation without stating the destination - Check claims again +--++---+--+--+ | resource_provider| generation | resources | project_id | user_id | +--++---+--+--+ | 229cce5f-3b87-438a-baa9-539be0fc9bd8 | 6 | {'VCPU': 1, 'MEMORY_MB': 256} | 4facfb06808a4621b4f47123a0184a4a | 15da82817e56446198fcdd870a45d8f4 | | 5395932e-b5e0-4a0c-be6a-7328af751642 | 14 | {'VCPU': 1, 'MEMORY_MB': 256} | 4facfb06808a4621b4f47123a0184a4a | 15da82817e56446198fcdd870a45d8f4 | +--+---
[Yahoo-eng-team] [Bug 1794718] [NEW] Neutron VPNAAS don't update site connections on python3
Public bug reported: Tested with StrongSwan but I hope this can cause issues on others drivers too. On python3 when new connection is created it's stuck in PENDING_CREATE state. Everything is working but connection state is never updated. Main reason is that agent send wrong id to server. On python3 message look like this: [{'updated_pending_status': False, 'ipsec_site_connections': {'a': {'updated_pending_status': False, 'status': 'ACTIVE'}}, 'status': 'ACTIVE', 'id': 'a621a382-308d-4cd0-be0a-01c757064a13'}, {'updated_pending_status': False, 'ipsec_site_connections': {'a': {'updated_pending_status': False, 'status': 'ACTIVE'}}, 'status': 'ACTIVE', 'id': 'd004c466-cc36-4b6b-8aa3-84d7e45569ad'}] on python2 [{'status': 'ACTIVE', 'ipsec_site_connections': {u'7e14400a-60df-48d8 -91aa-ec97749555fc': {'status': 'ACTIVE', 'updated_pending_status': False}}, 'updated_pending_status': False, 'id': u'c903732e- 67da-4363-baf1-0cdcb7476ee7'}, {'status': 'ACTIVE', 'ipsec_site_connections': {u'70671513-e0cf-4bdf-845e-cb6ef084baea': {'status': 'ACTIVE', 'updated_pending_status': True}}, 'updated_pending_status': True, 'id': u'995ed22c- 00c3-4496-b590-b84787ba6caa'}] Notice uid in ipsec_site_connections. Problem is that this uid is parsed from subprocess and on python3 this subprocess return bytes instead of string. Because of this whole output parsing i kind of screw up. We was able to fix this issue via patching netns_wrapper: diff --git a/neutron_vpnaas/services/vpn/common/netns_wrapper.py b/neutron_vpnaas/services/vpn/common/netns_wrapper.py index 77378dcc7..35614a717 100644 --- a/neutron_vpnaas/services/vpn/common/netns_wrapper.py +++ b/neutron_vpnaas/services/vpn/common/netns_wrapper.py @@ -23,6 +23,7 @@ from neutron.common import utils from oslo_config import cfg from oslo_log import log as logging from oslo_rootwrap import wrapper +from neutron_lib.utils import helpers import six from neutron_vpnaas._i18n import _ @@ -67,6 +68,8 @@ def execute(cmd): env=env) _stdout, _stderr = obj.communicate() +_stdout = helpers.safe_decode_utf8(_stdout) +_stderr = helpers.safe_decode_utf8(_stderr) msg = ('Command: %(cmd)s Exit code: %(returncode)s ' 'Stdout: %(stdout)s Stderr: %(stderr)s' % {'cmd': cmd, ** Affects: neutron Importance: Undecided Status: New ** Tags: python3 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1794718 Title: Neutron VPNAAS don't update site connections on python3 Status in neutron: New Bug description: Tested with StrongSwan but I hope this can cause issues on others drivers too. On python3 when new connection is created it's stuck in PENDING_CREATE state. Everything is working but connection state is never updated. Main reason is that agent send wrong id to server. On python3 message look like this: [{'updated_pending_status': False, 'ipsec_site_connections': {'a': {'updated_pending_status': False, 'status': 'ACTIVE'}}, 'status': 'ACTIVE', 'id': 'a621a382-308d-4cd0-be0a-01c757064a13'}, {'updated_pending_status': False, 'ipsec_site_connections': {'a': {'updated_pending_status': False, 'status': 'ACTIVE'}}, 'status': 'ACTIVE', 'id': 'd004c466-cc36-4b6b-8aa3-84d7e45569ad'}] on python2 [{'status': 'ACTIVE', 'ipsec_site_connections': {u'7e14400a-60df-48d8 -91aa-ec97749555fc': {'status': 'ACTIVE', 'updated_pending_status': False}}, 'updated_pending_status': False, 'id': u'c903732e- 67da-4363-baf1-0cdcb7476ee7'}, {'status': 'ACTIVE', 'ipsec_site_connections': {u'70671513-e0cf-4bdf-845e-cb6ef084baea': {'status': 'ACTIVE', 'updated_pending_status': True}}, 'updated_pending_status': True, 'id': u'995ed22c- 00c3-4496-b590-b84787ba6caa'}] Notice uid in ipsec_site_connections. Problem is that this uid is parsed from subprocess and on python3 this subprocess return bytes instead of string. Because of this whole output parsing i kind of screw up. We was able to fix this issue via patching netns_wrapper: diff --git a/neutron_vpnaas/services/vpn/common/netns_wrapper.py b/neutron_vpnaas/services/vpn/common/netns_wrapper.py index 77378dcc7..35614a717 100644 --- a/neutron_vpnaas/services/vpn/common/netns_wrapper.py +++ b/neutron_vpnaas/services/vpn/common/netns_wrapper.py @@ -23,6 +23,7 @@ from neutron.common import utils from oslo_config import cfg from oslo_log import log as logging from oslo_rootwrap import wrapper +from neutron_lib.utils import helpers import six from neutron_vpnaas._i18n import _ @@ -67,6 +68,8 @@ def execute(cmd): env=env) _stdout, _stderr = obj.communicate() +_stdout = helpers.safe_decode_utf8(_stdout) +_stderr = helpers.safe_decode_utf8(_stderr) msg = ('Command: %(cmd)s Exit code: %(returncode)s ' 'St