[Yahoo-eng-team] [Bug 1624277] [NEW] nova-scheduler: UnicodeDecodeError in host aggregates handling
Public bug reported: nova-scheduler doesn't seem to like when there are non-asci characters in the host aggregate objects. Steps to reproduce: 1. Create a host aggregate with some non-asci chars in properties, e.g.: $ openstack aggregate show test_aggr +---+--+ | Field | Value| +---+--+ | availability_zone | nova | | created_at| 2016-09-09T17:31:12.00 | | deleted | False| | deleted_at| None | | hosts | [u'node-6.domain.tld', u'node-7.domain.tld'] | | id| 54 | | name | test_aggr| | properties| test_meta='проверка мета'| | updated_at| None | +---+--+ 2. Start an instance Expected result: instance started. Actual result: instance creating failed, exception in the nova-scheduler.log attached. This is reproducible with Mitaka, didn't try master. ** Affects: nova Importance: Undecided Status: New ** Attachment added: "nova_scheduler_unicode_error.txt" https://bugs.launchpad.net/bugs/1624277/+attachment/4741874/+files/nova_scheduler_unicode_error.txt ** Description changed: nova-scheduler doesn't seem to like when there are non-asci characters in the host aggregate objects. Steps to reproduce: 1. Create a host aggregate with some non-asci chars in properties, e.g.: $ openstack aggregate show test_aggr +---+--+ | Field | Value| +---+--+ | availability_zone | nova | | created_at| 2016-09-09T17:31:12.00 | | deleted | False| | deleted_at| None | | hosts | [u'node-6.domain.tld', u'node-7.domain.tld'] | | id| 54 | | name | test_aggr| | properties| test_meta='проверка мета'| | updated_at| None | +---+--+ 2. Start an instance Expected result: instance started. Actual result: instance creating failed, exception in the nova-scheduler.log attached. + + This is reproducible with Mitaka, didn't try master. -- 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/1624277 Title: nova-scheduler: UnicodeDecodeError in host aggregates handling Status in OpenStack Compute (nova): New Bug description: nova-scheduler doesn't seem to like when there are non-asci characters in the host aggregate objects. Steps to reproduce: 1. Create a host aggregate with some non-asci chars in properties, e.g.: $ openstack aggregate show test_aggr +---+--+ | Field | Value| +---+--+ | availability_zone | nova | | created_at| 2016-09-09T17:31:12.00 | | deleted | False| | deleted_at| None | | hosts | [u'node-6.domain.tld', u'node-7.domain.tld'] | | id| 54 | | name | test_aggr| | properties| test_meta='проверка мета'| | updated_at| None | +---+--+ 2. Start an instance Expected result: instance started. Actual result: instance creating failed, exception in the nova-scheduler.log attached. This is reproducible with Mitaka, didn't try master. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1624277/+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 :
[Yahoo-eng-team] [Bug 1481274] [NEW] variable referenced before assignment error in keystone.contrib.federation.idp._sign_assertion
Public bug reported: The _sign_assertion() function from keystone.contrib.federation.idp assigns file_path variable in the try block and then tries to clean up the file in the finally block. However, if fileutils.write_to_tempfile call raises then file_path is not assigned that results in UnboundLocalError: File keystone/contrib/federation/idp.py, line 437, in _sign_assertion os.remove(file_path) UnboundLocalError: local variable 'file_path' referenced before assignment ** Affects: keystone Importance: Undecided Assignee: Roman Bogorodskiy (novel) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1481274 Title: variable referenced before assignment error in keystone.contrib.federation.idp._sign_assertion Status in Keystone: In Progress Bug description: The _sign_assertion() function from keystone.contrib.federation.idp assigns file_path variable in the try block and then tries to clean up the file in the finally block. However, if fileutils.write_to_tempfile call raises then file_path is not assigned that results in UnboundLocalError: File keystone/contrib/federation/idp.py, line 437, in _sign_assertion os.remove(file_path) UnboundLocalError: local variable 'file_path' referenced before assignment To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1481274/+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 1475256] [NEW] sriov: VFs attributes (vlan, mac address) are not cleaned up after port delete
Public bug reported:
Image we create a port like this:
$ neutron port-create --binding:vnic_type=direct --name rjuly013 sriovtest0
Created a new port:
+---+-+
| Field | Value
|
+---+-+
| admin_state_up| True
|
| allowed_address_pairs |
|
| binding:host_id |
|
| binding:profile | {}
|
| binding:vif_details | {}
|
| binding:vif_type | unbound
|
| binding:vnic_type | direct
|
| device_id |
|
| device_owner |
|
| fixed_ips | {subnet_id: ffa84ccf-ba49-4a23-a8ab-9295bc7d93f2,
ip_address: 166.168.0.15} |
| id| 2ec3b30e-e3cf-4a8f-a7cb-68a910a59e9a
|
| mac_address | fa:16:3e:ca:11:87
|
| name | rjuly013
|
| network_id| 26a0f22b-42b0-41d2-9b76-41270ce9b655
|
| security_groups | b0ef012a-96b2-458f-bd28-c46306f063fa
|
| status| DOWN
|
| tenant_id | 2ebabf166ecd43dd8093b70a37f26be4
|
+---+-+
$
And then create a VM with this port:
$ nova boot --image 3c3a5387-7471-4e88-a19e-09e0c9a08707 --flavor 3
--nic port-id=2ec3b30e-e3cf-4a8f-a7cb-68a910a59e9a rjuly013
Now we can see a VF configured:
$ ip link|grep fa:16:3e:ca:11:87
vf 7 MAC fa:16:3e:ca:11:87, spoof checking on, link-state auto
$
After deletion of VM, we can see that the VF is still configured:
$ ip link|grep fa:16:3e:ca:11:87
vf 7 MAC fa:16:3e:ca:11:87, spoof checking on, link-state auto
$
This situation could cause troubles, for example, if user would want to
create a new port with the mac address of the removed port, and if a
port would be allocated on the same PF, there would be 2 VFs with the
same MAC address in result. This could cause an unexpected behavior,
with 'ixgbe' at least.
** 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/1475256
Title:
sriov: VFs attributes (vlan, mac address) are not cleaned up after
port delete
Status in neutron:
New
Bug description:
Image we create a port like this:
$ neutron port-create --binding:vnic_type=direct --name rjuly013 sriovtest0
Created a new port:
+---+-+
| Field | Value
|
+---+-+
| admin_state_up| True
|
| allowed_address_pairs |
|
| binding:host_id |
|
| binding:profile | {}
|
| binding:vif_details | {}
|
| binding:vif_type | unbound
|
| binding:vnic_type | direct
|
| device_id |
[Yahoo-eng-team] [Bug 1468332] [NEW] sriov agent causes incorrect port state if sriov driver doesn't support 'ip link vf state' setting
Public bug reported: Some devices doesn't seem to support link state setting: ubuntu@devstack1:~$ ip l sh p2p1 189: p2p1: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 0c:c4:7a:1e:ac:0e brd ff:ff:ff:ff:ff:ff vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 2 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 3 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 4 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 5 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 6 MAC 00:00:00:00:00:00, spoof checking on, link-state auto ubuntu@devstack1:~$ ubuntu@devstack1:~$ sudo ip l set dev p2p1 vf 6 state disable RTNETLINK answers: Operation not supported ubuntu@devstack1:~$ ubuntu@devstack1:~$ ls -all /sys/class/net/p2p1/device/driver/module lrwxrwxrwx 1 root root 0 Jun 24 14:30 /sys/class/net/p2p1/device/driver/module - ../../../../module/ixgbe ubuntu@devstack1:~$ As you can see, this happens with the 'ixgbe' driver. This confuses sriov agent: In neutron/plugins/sriovnicagent/sriov_nic_agent.py there's a 'treat_device' method that's called after port binding for example. The sriov agent tries to set VF state to UP and fails, so the code doesn't reach self.plugin_rpc.update_device_up() and the port ends up hanging in BUILD state. ** Affects: neutron Importance: Undecided Assignee: Roman Bogorodskiy (novel) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1468332 Title: sriov agent causes incorrect port state if sriov driver doesn't support 'ip link vf state' setting Status in OpenStack Neutron (virtual network service): In Progress Bug description: Some devices doesn't seem to support link state setting: ubuntu@devstack1:~$ ip l sh p2p1 189: p2p1: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 0c:c4:7a:1e:ac:0e brd ff:ff:ff:ff:ff:ff vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 2 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 3 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 4 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 5 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 6 MAC 00:00:00:00:00:00, spoof checking on, link-state auto ubuntu@devstack1:~$ ubuntu@devstack1:~$ sudo ip l set dev p2p1 vf 6 state disable RTNETLINK answers: Operation not supported ubuntu@devstack1:~$ ubuntu@devstack1:~$ ls -all /sys/class/net/p2p1/device/driver/module lrwxrwxrwx 1 root root 0 Jun 24 14:30 /sys/class/net/p2p1/device/driver/module - ../../../../module/ixgbe ubuntu@devstack1:~$ As you can see, this happens with the 'ixgbe' driver. This confuses sriov agent: In neutron/plugins/sriovnicagent/sriov_nic_agent.py there's a 'treat_device' method that's called after port binding for example. The sriov agent tries to set VF state to UP and fails, so the code doesn't reach self.plugin_rpc.update_device_up() and the port ends up hanging in BUILD state. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1468332/+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 1467145] [NEW] Socket related unit tests fail on FreeBSD
Public bug reported: Due to different behavior of SO_REUSEADDR on Linux and BSD some unit tests fail, e.g.: nova.tests.unit.test_wsgi.TestWSGIServer.test_socket_options_for_simple_server -- Captured traceback: ~~~ Traceback (most recent call last): File nova/tests/unit/test_wsgi.py, line 140, in test_socket_options_for_simple_server socket.SO_REUSEADDR)) File /usr/home/novel/code/openstack/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py, line 350, in assertEqual self.assertThat(observed, matcher, message) File /usr/home/novel/code/openstack/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py, line 435, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: 1 != 4 Captured pythonlogging: ~~~ 2015-06-20 17:32:52,230 INFO [nova.wsgi] test_socket_options listening on 127.0.0.1:60566 Similar (or I'd say the same) problem was reported and fixed for OS X: https://bugs.launchpad.net/nova/+bug/1436895 ** Affects: nova Importance: Undecided Assignee: Roman Bogorodskiy (novel) Status: In Progress -- 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/1467145 Title: Socket related unit tests fail on FreeBSD Status in OpenStack Compute (Nova): In Progress Bug description: Due to different behavior of SO_REUSEADDR on Linux and BSD some unit tests fail, e.g.: nova.tests.unit.test_wsgi.TestWSGIServer.test_socket_options_for_simple_server -- Captured traceback: ~~~ Traceback (most recent call last): File nova/tests/unit/test_wsgi.py, line 140, in test_socket_options_for_simple_server socket.SO_REUSEADDR)) File /usr/home/novel/code/openstack/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py, line 350, in assertEqual self.assertThat(observed, matcher, message) File /usr/home/novel/code/openstack/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py, line 435, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: 1 != 4 Captured pythonlogging: ~~~ 2015-06-20 17:32:52,230 INFO [nova.wsgi] test_socket_options listening on 127.0.0.1:60566 Similar (or I'd say the same) problem was reported and fixed for OS X: https://bugs.launchpad.net/nova/+bug/1436895 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1467145/+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
