[Yahoo-eng-team] [Bug 1528468] [NEW] can create a security group rule with icmp option while ipv6 ether type is set
Public bug reported: [Summary] can create a security group rule with icmp option while ipv6 ether type is set [Topo] devstack all-in-one [Description and expect result] should return an error if create a security group rule with icmp option while ipv6 ether type is set [Reproduceable or not] reproduceable [Recreate Steps] 1) create a security group rule as below: root@45-59:/opt/stack/devstack# neutron security-group-rule-create --protocol icmp --ethertype ipv6 sg1 Created a new security_group_rule: +---+--+ | Field | Value| +---+--+ | direction | ingress | | ethertype | IPv6 | | id| 303c6aa8-0937-4ed9-89d5-2733febe72a0 | | port_range_max| | | port_range_min| | | protocol | icmp | | remote_group_id | | | remote_ip_prefix | | | security_group_id | 4fd891e1-4de0-42aa-8fcd-3fd34a978d0e | | tenant_id | fb3af4173e8e42bca61dca2175ec3774 | +---+--+ 2)for reference, when create a security group rule with icmpv6 option while ipv4 ether type is set, an error message returned: root@45-59:/opt/stack/devstack# neutron security-group-rule-create --protocol icmpv6 --ethertype ipv4 sg1 Invalid ethertype IPv4 for protocol icmpv6. root@45-59:/opt/stack/devstack# [Configration] reproduceable bug, no need [logs] reproduceable bug, no need [Root cause anlyze or debug inf] reproduceable bug [Attachment] None ** 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/1528468 Title: can create a security group rule with icmp option while ipv6 ether type is set Status in neutron: New Bug description: [Summary] can create a security group rule with icmp option while ipv6 ether type is set [Topo] devstack all-in-one [Description and expect result] should return an error if create a security group rule with icmp option while ipv6 ether type is set [Reproduceable or not] reproduceable [Recreate Steps] 1) create a security group rule as below: root@45-59:/opt/stack/devstack# neutron security-group-rule-create --protocol icmp --ethertype ipv6 sg1 Created a new security_group_rule: +---+--+ | Field | Value| +---+--+ | direction | ingress | | ethertype | IPv6 | | id| 303c6aa8-0937-4ed9-89d5-2733febe72a0 | | port_range_max| | | port_range_min| | | protocol | icmp | | remote_group_id | | | remote_ip_prefix | | | security_group_id | 4fd891e1-4de0-42aa-8fcd-3fd34a978d0e | | tenant_id | fb3af4173e8e42bca61dca2175ec3774 | +---+--+ 2)for reference, when create a security group rule with icmpv6 option while ipv4 ether type is set, an error message returned: root@45-59:/opt/stack/devstack# neutron security-group-rule-create --protocol icmpv6 --ethertype ipv4 sg1 Invalid ethertype IPv4 for protocol icmpv6. root@45-59:/opt/stack/devstack# [Configration] reproduceable bug, no need [logs] reproduceable bug, no need [Root cause anlyze or debug inf] reproduceable bug [Attachment] None To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1528468/+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 1528467] [NEW] can create a security group rule with icmp option while ipv6 ether type is set
Public bug reported: [Summary] can create a security group rule with icmp option while ipv6 ether type is set [Topo] devstack all-in-one [Description and expect result] should return an error if create a security group rule with icmp option while ipv6 ether type is set [Reproduceable or not] reproduceable [Recreate Steps] 1) create a security group rule as below: root@45-59:/opt/stack/devstack# neutron security-group-rule-create --protocol icmp --ethertype ipv6 sg1 Created a new security_group_rule: +---+--+ | Field | Value| +---+--+ | direction | ingress | | ethertype | IPv6 | | id| 303c6aa8-0937-4ed9-89d5-2733febe72a0 | | port_range_max| | | port_range_min| | | protocol | icmp | | remote_group_id | | | remote_ip_prefix | | | security_group_id | 4fd891e1-4de0-42aa-8fcd-3fd34a978d0e | | tenant_id | fb3af4173e8e42bca61dca2175ec3774 | +---+--+ 2)for reference, when create a security group rule with icmpv6 option while ipv4 ether type is set, an error message returned: root@45-59:/opt/stack/devstack# neutron security-group-rule-create --protocol icmpv6 --ethertype ipv4 sg1 Invalid ethertype IPv4 for protocol icmpv6. root@45-59:/opt/stack/devstack# [Configration] reproduceable bug, no need [logs] reproduceable bug, no need [Root cause anlyze or debug inf] reproduceable bug [Attachment] None ** Affects: neutron Importance: Undecided Status: Invalid ** 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. https://bugs.launchpad.net/bugs/1528467 Title: can create a security group rule with icmp option while ipv6 ether type is set Status in neutron: Invalid Bug description: [Summary] can create a security group rule with icmp option while ipv6 ether type is set [Topo] devstack all-in-one [Description and expect result] should return an error if create a security group rule with icmp option while ipv6 ether type is set [Reproduceable or not] reproduceable [Recreate Steps] 1) create a security group rule as below: root@45-59:/opt/stack/devstack# neutron security-group-rule-create --protocol icmp --ethertype ipv6 sg1 Created a new security_group_rule: +---+--+ | Field | Value| +---+--+ | direction | ingress | | ethertype | IPv6 | | id| 303c6aa8-0937-4ed9-89d5-2733febe72a0 | | port_range_max| | | port_range_min| | | protocol | icmp | | remote_group_id | | | remote_ip_prefix | | | security_group_id | 4fd891e1-4de0-42aa-8fcd-3fd34a978d0e | | tenant_id | fb3af4173e8e42bca61dca2175ec3774 | +---+--+ 2)for reference, when create a security group rule with icmpv6 option while ipv4 ether type is set, an error message returned: root@45-59:/opt/stack/devstack# neutron security-group-rule-create --protocol icmpv6 --ethertype ipv4 sg1 Invalid ethertype IPv4 for protocol icmpv6. root@45-59:/opt/stack/devstack# [Configration] reproduceable bug, no need [logs] reproduceable bug, no need [Root cause anlyze or debug inf] reproduceable bug [Attachment] None To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1528467/+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 1528465] [NEW] dashboard project network column display duplicate default public network randomly
Public bug reported: dashboard project network column display duplicate default public network randomly. this occurs randomly setup: devstack reproduce: yes steps: 1.check default public network we have stack@45-59:~/devstack$ neutron net-list +--+-+--+ | id | name| subnets | +--+-+--+ | 1931775c-4459-4c18-9910-53b1ffbe4d31 | private | 9b1a99a3-e7ae-4a7d-b9d2-e035077d4e5e 10.0.0.0/24 | | | | 3ebaa37a-2b80-4186-9357-dd8b1202d542 fd7e:7e2b:56d0::/64 | | b9cedb82-6835-499b-885d-7646416ac93f | public | aea6ea63-b70c-49fe-9bf5-3f593015a07d 172.24.4.0/24 | | | | 146a2d03-52e0-4c7d-ba77-a9a2df99da7f 2001:db8::/64 | 2.check this on dashborad, we find that it displays two duplicate public network. this occurs randomly ** Affects: horizon Importance: Undecided Status: New ** Summary changed: - dashboard project network column display duplicate default public network + dashboard project network column display duplicate default public network randomly ** Description changed: dashboard project network column display duplicate default public - network. this occurs randomly + network randomly. this occurs randomly setup: devstack reproduce: yes steps: 1.check default public network we have stack@45-59:~/devstack$ neutron net-list +--+-+--+ | id | name| subnets | +--+-+--+ | 1931775c-4459-4c18-9910-53b1ffbe4d31 | private | 9b1a99a3-e7ae-4a7d-b9d2-e035077d4e5e 10.0.0.0/24 | | | | 3ebaa37a-2b80-4186-9357-dd8b1202d542 fd7e:7e2b:56d0::/64 | | b9cedb82-6835-499b-885d-7646416ac93f | public | aea6ea63-b70c-49fe-9bf5-3f593015a07d 172.24.4.0/24 | | | | 146a2d03-52e0-4c7d-ba77-a9a2df99da7f 2001:db8::/64 | - - 2.check this on dashborad, we find that it displays two duplicate public network. this occurs randomly + 2.check this on dashborad, we find that it displays two duplicate public + network. this occurs randomly -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1528465 Title: dashboard project network column display duplicate default public network randomly Status in OpenStack Dashboard (Horizon): New Bug description: dashboard project network column display duplicate default public network randomly. this occurs randomly setup: devstack reproduce: yes steps: 1.check default public network we have stack@45-59:~/devstack$ neutron net-list +--+-+--+ | id | name| subnets | +--+-+--+ | 1931775c-4459-4c18-9910-53b1ffbe4d31 | private | 9b1a99a3-e7ae-4a7d-b9d2-e035077d4e5e 10.0.0.0/24 | | | | 3ebaa37a-2b80-4186-9357-dd8b1202d542 fd7e:7e2b:56d0::/64 | | b9cedb82-6835-499b-885d-7646416ac93f | public | aea6ea63-b70c-49fe-9bf5-3f593015a07d 172.24.4.0/24 | | | | 146a2d03-52e0-4c7d-ba77-a9a2df99da7f 2001:db8::/64 | 2.check this on dashborad, we find that it displays two duplicate public network. this occurs randomly To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1528465/+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 1528455] [NEW] can launch an instance with fixed ipv4 address using v6-fixed-ip option
Public bug reported:
[Summary]
can launch an instance with fixed ipv4 address using v6-fixed-ip option
[Topo]
devstack all-in-one node
[Description and expect result]
should return an error if launch an instance with fixed ipv4 address using
v6-fixed-ip option
[Reproduceable or not]
reproduceable
[Recreate Steps]
1) create a subnet :
root@45-59:/opt/stack/devstack# nova boot --flavor 1 --image
cirros-0.3.4-x86_64-uec --availability-zone nova --nic
net-id=1b72073d-e7c0-4bbd-b9f0-f834e5ff1fa7,v6-fixed-ip=1.0.0.100 instance-1
+--++
| Property | Value
|
+--++
| OS-DCF:diskConfig| MANUAL
|
| OS-EXT-AZ:availability_zone | nova
|
| OS-EXT-STS:power_state | 0
|
| OS-EXT-STS:task_state| scheduling
|
| OS-EXT-STS:vm_state | building
|
| OS-SRV-USG:launched_at | -
|
| OS-SRV-USG:terminated_at | -
|
| accessIPv4 |
|
| accessIPv6 |
|
| adminPass| i8VQC4fZSsMp
|
| config_drive |
|
| created | 2015-12-22T14:15:22Z
|
| flavor | m1.tiny (1)
|
| hostId |
|
| id | 03e248ee-821a-4b37-81e0-5692102956fb
|
| image| cirros-0.3.4-x86_64-uec
(e3e3fd4e-ea26-47d6-b442-76d36ff7d283) |
| key_name | -
|
| metadata | {}
|
| name | instance-1
|
| os-extended-volumes:volumes_attached | []
|
| progress | 0
|
| security_groups | default
|
| status | BUILD
|
| tenant_id| fb3af4173e8e42bca61dca2175ec3774
|
| updated | 2015-12-22T14:15:23Z
|
| user_id | e266d2b5fd004f71b6ffadb37cc38813
|
+--++
root@45-59:/opt/stack/devstack#
root@45-59:/opt/stack/devstack# nova list
+--++++-++
| ID | Name | Status | Task State |
Power State | Networks |
+--++++-++
| 03e248ee-821a-4b37-81e0-5692102956fb | instance-1 | ACTIVE | - |
Running | net1=1.0.0.100 |
+--++++-++
root@45-59:/opt/stack/devstack#
[Configration]
reproduceable bug, no need
[logs]
reproduceable bug, no need
[Root cause anlyze or debug inf]
reproduceable bug
[Attachment]
None
** 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/1528455
Title:
can launch an instance with fixed ipv4 address using v6-fixed-ip
option
Status in OpenStack Compute (nova):
New
Bug description:
[Summary]
can launch an instance with fixed ipv4 address
[Yahoo-eng-team] [Bug 1528453] [NEW] Provide a ranking mechanism for glance-api to order locations
Public bug reported: We have a setup consisting of multiple cells with their own glance-api servers. We have a global swift store that holds all the images, and we are exploring having local stores to increase efficiency. This can be done using image-locations in glance. (Thanks!) However, currently it is not possible for each cell to specify their custom ordering of image locations. The store_type location strategy does not work because more than one cell can have the same type of backend. If this is made possible, each cell can return the closest location for each glance image, and also do copy-on-write for local stores like RBD. This can be achieved by having another location_strategy that orders based on a ranking key in metadata. Opening a bug but I'll like this classified as a wishlist. Comments and suggestions are welcome! ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1528453 Title: Provide a ranking mechanism for glance-api to order locations Status in Glance: New Bug description: We have a setup consisting of multiple cells with their own glance-api servers. We have a global swift store that holds all the images, and we are exploring having local stores to increase efficiency. This can be done using image-locations in glance. (Thanks!) However, currently it is not possible for each cell to specify their custom ordering of image locations. The store_type location strategy does not work because more than one cell can have the same type of backend. If this is made possible, each cell can return the closest location for each glance image, and also do copy-on-write for local stores like RBD. This can be achieved by having another location_strategy that orders based on a ranking key in metadata. Opening a bug but I'll like this classified as a wishlist. Comments and suggestions are welcome! To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1528453/+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 1528439] [NEW] Rebuild instance do not rebuild cinder ceph volumes
Public bug reported: When I exec function Rebuild instance ==> chose image for rebuild After function complete I check and I see cinder volumes do not rebuild as image that I chosen , just same as before Rebuild work as my expect when instance create and boot from image, if boot from image and create volume, rebuild do not work as expect. Please help me fix this, thank My system is - Openstack Kilo latest build - Ceph 0.94 hammer - Ubuntu 14.04 ** Affects: cinder Importance: Undecided Status: New ** Affects: nova Importance: Undecided Status: New ** Tags: cinder ** Also affects: cinder 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/1528439 Title: Rebuild instance do not rebuild cinder ceph volumes Status in Cinder: New Status in OpenStack Compute (nova): New Bug description: When I exec function Rebuild instance ==> chose image for rebuild After function complete I check and I see cinder volumes do not rebuild as image that I chosen , just same as before Rebuild work as my expect when instance create and boot from image, if boot from image and create volume, rebuild do not work as expect. Please help me fix this, thank My system is - Openstack Kilo latest build - Ceph 0.94 hammer - Ubuntu 14.04 To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1528439/+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 1527661] Re: Create new instance boot from rbd image failed (no image created in VMS pools), after upgrade lastest kilo build
edit, I find problem cause by NFS file system can not lock file, reboot NFS service have no luck, I must reboot NFS server Now it worked correctly. This problem cause by update NFS service ** Changed in: nova Status: New => Invalid ** Changed in: nova (Ubuntu) Status: New => Invalid -- 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/1527661 Title: Create new instance boot from rbd image failed (no image created in VMS pools),after upgrade lastest kilo build Status in OpenStack Compute (nova): Invalid Status in nova package in Ubuntu: Invalid Bug description: After upgrade to the lastest version of openstack kilo, when i boot new instance from image the instance started failed with error message below. I see nova do not create RBD volumes of glance image to Ceph VMS pool, this affect to swap and Ephemeral disk too my system worked correctly before. Please check my attach file for detail === 2015-12-18 22:07:56.590 1620300 DEBUG nova.virt.libvirt.rbd_utils [req-eab9562d-484f-432d-a9d7-0ab32ec99c23 0690b97b2bea47a8aeb4777856f473b2 767b2f8a8b08403884269836420d34f0 - - -] rbd image 352eb808-f7c3-405d-92b4-c29bf07a46f0_disk does not exist __init__ /usr/lib/python2.7/dist-packages/nova/virt/libvirt/rbd_utils.py:60 2015-12-18 22:07:56.641 1620300 DEBUG nova.virt.libvirt.rbd_utils [req-eab9562d-484f-432d-a9d7-0ab32ec99c23 0690b97b2bea47a8aeb4777856f473b2 767b2f8a8b08403884269836420d34f0 - - -] rbd image 352eb808-f7c3-405d-92b4-c29bf07a46f0_disk does not exist __init__ /usr/lib/python2.7/dist-packages/nova/virt/libvirt/rbd_utils.py:60 2015-12-18 22:15:12.033 1620300 DEBUG nova.virt.libvirt.rbd_utils [req-c07f3a3b-82de-41b5-9f91-e52a2295b0fa 0690b97b2bea47a8aeb4777856f473b2 767b2f8a8b08403884269836420d34f0 - - -] rbd image 40df5d10-6af1-49ea-bb5f-37a5e6ffa053_disk does not exist __init__ /usr/lib/python2.7/dist-packages/nova/virt/libvirt/rbd_utils.py:60 2015-12-18 22:15:12.093 1620300 DEBUG nova.virt.libvirt.rbd_utils [req-c07f3a3b-82de-41b5-9f91-e52a2295b0fa 0690b97b2bea47a8aeb4777856f473b2 767b2f8a8b08403884269836420d34f0 - - -] rbd image 40df5d10-6af1-49ea-bb5f-37a5e6ffa053_disk does not exist __init__ /usr/lib/python2.7/dist-packages/nova/virt/libvirt/rbd_utils.py:60 # 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] do_log=False, semaphores=semaphores, delay=delay): 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] File "/usr/lib/python2.7/contextlib.py", line 17, in __ent er__ 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] return self.gen.next() 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] File "/usr/lib/python2.7/dist-packages/oslo_concurrency/lo ckutils.py", line 395, in lock 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] ext_lock.acquire(delay=delay) 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] File "/usr/lib/python2.7/dist-packages/oslo_concurrency/lo ckutils.py", line 209, in acquire 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] do_acquire() 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] File "/usr/lib/python2.7/dist-packages/oslo_concurrency/lo ckutils.py", line 158, in wrapper 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] return r.call(func, *args, **kwargs) 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] File "/usr/lib/python2.7/dist-packages/retrying.py", line 222, in call 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] if not self.should_reject(attempt): 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] File "/usr/lib/python2.7/dist-packages/retrying.py", line 206, in should_reject 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] reject |= self._retry_on_exception(attempt.value[1]) 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] File "/usr/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 130, in retry_on_exception 2015-12-18 22:27:48.308 1623512 TRACE nova.compute.manager [instance: 3bf19259-4a86-4b9e-b358-15e59470231d] '
[Yahoo-eng-team] [Bug 1528435] [NEW] The gate test of VPNaaS is failing with AttributeError
Public bug reported: When I run git review command on today(AM 10:00), the gate test of VPNaaS is failing with following error. There are 5 errors and all of errors are AttributeError. I guess that following recent modification affects https://github.com/openstack/neutron/commit/dd5f5716c9a32634caa2a44d362cd77461ba873d *Error details Traceback (most recent call last): File "/home/ubuntu/for_commit/midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_db/api.py", line 137, in wrapper return f(*args, **kwargs) File "/home/ubuntu/for_commit/midonet/.tox/py27/src/neutron/neutron/api/v2/base.py", line 414, in create allow_bulk=self._allow_bulk) File "/home/ubuntu/for_commit/midonet/.tox/py27/src/neutron/neutron/api/v2/base.py", line 680, in prepare_request_body attributes.convert_value(attr_info, res_dict, webob.exc.HTTPBadRequest) File "/home/ubuntu/for_commit/midonet/.tox/py27/src/neutron/neutron/api/v2/attributes.py", line 919, in convert_value res = validators[rule](res_dict[attr], attr_vals['validate'][rule]) File "/home/ubuntu/for_commit/midonet/.tox/py27/src/neutron-vpnaas/neutron_vpnaas/extensions/vpnaas.py", line 167, in _validate_subnet_list_or_none attr._validate_subnet_list(data, key_specs) AttributeError: 'module' object has no attribute '_validate_subnet_list' 2015-12-22 02:24:21,828ERROR [neutron.api.v2.resource] create failed Traceback (most recent call last): File "/home/ubuntu/for_commit/midonet/.tox/py27/src/neutron/neutron/api/v2/resource.py", line 83, in resource result = method(request=request, **args) File "/home/ubuntu/for_commit/midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_db/api.py", line 152, in wrapper ectxt.value = e.inner_exc File "/home/ubuntu/for_commit/midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/excutils.py", line 204, in __exit__ six.reraise(self.type_, self.value, self.tb) File "/home/ubuntu/for_commit/midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_db/api.py", line 137, in wrapper return f(*args, **kwargs) File "/home/ubuntu/for_commit/midonet/.tox/py27/src/neutron/neutron/api/v2/base.py", line 414, in create allow_bulk=self._allow_bulk) File "/home/ubuntu/for_commit/midonet/.tox/py27/src/neutron/neutron/api/v2/base.py", line 680, in prepare_request_body attributes.convert_value(attr_info, res_dict, webob.exc.HTTPBadRequest) File "/home/ubuntu/for_commit/midonet/.tox/py27/src/neutron/neutron/api/v2/attributes.py", line 919, in convert_value res = validators[rule](res_dict[attr], attr_vals['validate'][rule]) File "/home/ubuntu/for_commit/midonet/.tox/py27/src/neutron-vpnaas/neutron_vpnaas/extensions/vpnaas.py", line 167, in _validate_subnet_list_or_none attr._validate_subnet_list(data, key_specs) AttributeError: 'module' object has no attribute '_validate_subnet_list' ** Affects: neutron Importance: Undecided Status: Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1528435 Title: The gate test of VPNaaS is failing with AttributeError Status in neutron: Confirmed Bug description: When I run git review command on today(AM 10:00), the gate test of VPNaaS is failing with following error. There are 5 errors and all of errors are AttributeError. I guess that following recent modification affects https://github.com/openstack/neutron/commit/dd5f5716c9a32634caa2a44d362cd77461ba873d *Error details Traceback (most recent call last): File "/home/ubuntu/for_commit/midonet/.tox/py27/local/lib/python2.7/site-packages/oslo_db/api.py", line 137, in wrapper return f(*args, **kwargs) File "/home/ubuntu/for_commit/midonet/.tox/py27/src/neutron/neutron/api/v2/base.py", line 414, in create allow_bulk=self._allow_bulk) File "/home/ubuntu/for_commit/midonet/.tox/py27/src/neutron/neutron/api/v2/base.py", line 680, in prepare_request_body attributes.convert_value(attr_info, res_dict, webob.exc.HTTPBadRequest) File "/home/ubuntu/for_commit/midonet/.tox/py27/src/neutron/neutron/api/v2/attributes.py", line 919, in convert_value res = validators[rule](res_dict[attr], attr_vals['validate'][rule]) File "/home/ubuntu/for_commit/midonet/.tox/py27/src/neutron-vpnaas/neutron_vpnaas/extensions/vpnaas.py", line 167, in _validate_subnet_list_or_none attr._validate_subnet_list(data, key_specs) AttributeError: 'module' object has no attribute '_validate_subnet_list' 2015-12-22 02:24:21,828ERROR [neutron.api.v2.resource] create failed Traceback (most recent call last): File "/home/ubuntu/for_commit/midonet/.tox/py27/src/neutron/neutron/api/v2/resource.py", line 8
[Yahoo-eng-team] [Bug 1509121] Re: [UI] job_binaries Exception Value: too many values to unpack
The UI bug is not in Horizon, it's in the Sahara Dashboard which is
external to Horizon now. I'm marking the horizon aspect of this bug
invalid, but can't actually reassign that to Sahara because Launchpad
already has a Sahara component on this bug report (I think).
** Changed in: horizon
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1509121
Title:
[UI] job_binaries Exception Value: too many values to unpack
Status in OpenStack Dashboard (Horizon):
Invalid
Status in Sahara:
Fix Released
Bug description:
I accidentally created a Sahara EDP Job Binary, in RDO Kilo, with the
following properties:
Name
Binary
ID
c1fa1a5b-2458-43cc-9fbc-52a54fe74009
URL
swift://swift://container.sahara/Test-Private-Container/
Description
None
When I try to "Delete the Job Binary" the Dashboard displays a full-
page exception. Here is the Traceback:
Environment:
Request Method: POST
Request URL: https://my.org/dashboard/project/data_processing/job_binaries/
Django Version: 1.8.3
Python Version: 2.7.5
Installed Applications:
['openstack_dashboard.dashboards.project',
'openstack_dashboard.dashboards.admin',
'openstack_dashboard.dashboards.identity',
'openstack_dashboard.dashboards.settings',
'openstack_dashboard',
'django.contrib.contenttypes',
'django.contrib.auth',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'django.contrib.humanize',
'django_pyscss',
'openstack_dashboard.django_pyscss_fix',
'compressor',
'horizon',
'openstack_auth']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'horizon.middleware.HorizonMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware')
Traceback:
File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py" in
get_response
132. response = wrapped_callback(request,
*callback_args, **callback_kwargs)
File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec
36. return view_func(request, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec
52. return view_func(request, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec
36. return view_func(request, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec
84. return view_func(request, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/django/views/generic/base.py" in view
71. return self.dispatch(request, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/django/views/generic/base.py" in
dispatch
89. return handler(request, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in post
223. return self.get(request, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in get
159. handled = self.construct_tables()
File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in
construct_tables
150. handled = self.handle_table(table)
File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in
handle_table
125. handled = self._tables[name].maybe_handle()
File "/usr/lib/python2.7/site-packages/horizon/tables/base.py" in maybe_handle
1640. return self.take_action(action_name, obj_id)
File "/usr/lib/python2.7/site-packages/horizon/tables/base.py" in take_action
1482. response = action.multiple(self, self.request,
obj_ids)
File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py" in multiple
302. return self.handle(data_table, request, object_ids)
File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py" in handle
827. exceptions.handle(request, ignore=ignore)
File "/usr/lib/python2.7/site-packages/horizon/exceptions.py" in handle
364. six.reraise(exc_type, exc_value, exc_traceback)
File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py" in handle
811. self.action(request, datum_id)
File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py" in action
926. return self.delete(request, obj_id)
File
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/data_processing/job_binaries/tab
[Yahoo-eng-team] [Bug 1287851] Re: Under heavy load, neutron keeps retrying to connect to RabbitMQ
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1287851 Title: Under heavy load, neutron keeps retrying to connect to RabbitMQ Status in neutron: Expired Bug description: Under heavy load on Neutron, we observed that Neutron keeps retrying to connect to RabbitMQ. This behavior can be reproduced by having a lot of get ports/networks requests on Neutron and sneaking in any request (such as create port) that results in a notification message sent to RabbitMQ in-between. In the logs, we see a lot of ‘AMQP server on hostname:port is unreachable’ messages. This could be a bug with kombu in oslo, I'm not sure. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1287851/+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 1177106] Re: get_sync_data should not be part of the db class for the l3 API
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1177106 Title: get_sync_data should not be part of the db class for the l3 API Status in neutron: Expired Bug description: get_sync_data collects information to be sent to the l3 agent for synchronizing logical router state. However, several quantum plugins, which use this mixin, do not leverage the l3 agent. This code should therefore be moved away from the db class, ensuring on the other hand that the routine is still called by every plugin which uses the l3 agent. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1177106/+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 1409774] Re: sqlalchemy session needs to be rolled back after catching a db exception
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1409774 Title: sqlalchemy session needs to be rolled back after catching a db exception Status in neutron: Expired Bug description: To avoid errors like this: sqlalchemy.exc.InvalidRequestError: This Session's transaction has been rolled back by a nested rollback() call. To begin a new transaction, issue Session.rollback() first the sqlalchemy session needs to be rolled back after catching a db exception in a transaction, see sqlalchemy faq http://docs.sqlalchemy.org/en/rel_0_8/faq.html#this-session-s -transaction-has-been-rolled-back-due-to-a-previous-exception-during- flush-or-similar . There are places in Neutron code where a db exception is caught and the session is not properly rolled back. As explained in the sqlalchemy faq, this is the right way: try: session.commit() except: session.rollback() raise finally: session.close() # optional, depends on use case To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1409774/+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 1498288] Re: Low throughput with LBaaS(haproxy)
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1498288 Title: Low throughput with LBaaS(haproxy) Status in neutron: Expired Bug description: We have a Juno based openstack cloud build using Packstack. Controller node, network node and computes nodes each are running on a bare metal servers with LBaaS agent running on the network node. We are noticing a low throughput of 1G - 1.2G with HAproxy on a 10G link. We are measuring the throughput using iperf tool for the HAProxy. We have client on one compute node and the servers on different compute nodes which are linked via 10G . We changed the MTU size from 1400 to 9000 but received the same throughput. client 10G > LB namespace(HAproxy) - 10G ---> servers root@instance-0098:/# iperf -c 20.1.1.200 -i 1 -t 5 -M 1400 WARNING: attempt to set TCP maximum segment size to 1400, but got 536 Client connecting to 20.1.1.200, TCP port 5001 TCP window size: 22.0 KByte (default) [ 3] local 20.1.1.108 port 54438 connected with 20.1.1.200 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 120 MBytes 1.01 Gbits/sec [ 3] 1.0- 2.0 sec 140 MBytes 1.17 Gbits/sec [ 3] 2.0- 3.0 sec 138 MBytes 1.16 Gbits/sec [ 3] 3.0- 4.0 sec 135 MBytes 1.13 Gbits/sec Please let me know if we can tweet any parameter to increase the throughput. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1498288/+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 1528425] [NEW] memoized decorator not safe constructing a neutronclient in neutron api
Public bug reported: in /horizon/openstack_dashboard/api/neutron.py: @memoized def neutronclient(request): @memoized only take the request's fileds as key to index cache, but if a filed has a different descendant filed, cache will still hit. when we reuse the request with new parameters when calling neutron api, return same responses unexpectedly. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1528425 Title: memoized decorator not safe constructing a neutronclient in neutron api Status in OpenStack Dashboard (Horizon): New Bug description: in /horizon/openstack_dashboard/api/neutron.py: @memoized def neutronclient(request): @memoized only take the request's fileds as key to index cache, but if a filed has a different descendant filed, cache will still hit. when we reuse the request with new parameters when calling neutron api, return same responses unexpectedly. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1528425/+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 1528420] [NEW] netowrk information missed in dashboard network column
Public bug reported: setup inforamtion: devstack reproduce: yes steps: 1.install one devstack. source accrc/admin/admin 2.check devstack default netowrk inforamtion by using command. we have two network. stack@45-59:~/devstack$ neutron net-list +--+-+--+ | id | name| subnets | +--+-+--+ | b9cedb82-6835-499b-885d-7646416ac93f | public | 146a2d03-52e0-4c7d-ba77-a9a2df99da7f 2001:db8::/64 | | | | aea6ea63-b70c-49fe-9bf5-3f593015a07d 172.24.4.0/24 | | 1931775c-4459-4c18-9910-53b1ffbe4d31 | private | 9b1a99a3-e7ae-4a7d-b9d2-e035077d4e5e 10.0.0.0/24 | | | | 3ebaa37a-2b80-4186-9357-dd8b1202d542 fd7e:7e2b:56d0::/64 | +--+-+--+ 3.we can create instance with these network by using command. 4.check devstack dashboard gui. I find that we can't display private network. only public network is listed on the network column. but in admin column, we can see networks are all there. when try to launch a instance, we only can see network named public listed to be chosen for instance. 5.create a new private network by using command. we can see the created network linwwu. (neutron) net-create --prefix 192.168.1.0/24 linwwu Created a new network: +---+--+ | Field | Value| +---+--+ | admin_state_up| True | | availability_zone_hints | [] | | id| 000505b3-5498-4a9f-b269-5d165192474b | | mtu | 0| | name | linwwu | | port_security_enabled | True | | provider:network_type | vxlan| | provider:physical_network | | | provider:segmentation_id | 1023 | | router:external | False| | shared| False| | status| ACTIVE | | subnets | | | tenant_id | 4d2c7b5c5e2d4d7584ec5dac8e49343d | +---+--+ summary: we can't see default network named privated in dashboard gui, which should be displayed in network column. and when creating instance, we also can't see and choose the default private network. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1528420 Title: netowrk information missed in dashboard network column Status in OpenStack Dashboard (Horizon): New Bug description: setup inforamtion: devstack reproduce: yes steps: 1.install one devstack. source accrc/admin/admin 2.check devstack default netowrk inforamtion by using command. we have two network. stack@45-59:~/devstack$ neutron net-list +--+-+--+ | id | name| subnets | +--+-+--+ | b9cedb82-6835-499b-885d-7646416ac93f | public | 146a2d03-52e0-4c7d-ba77-a9a2df99da7f 2001:db8::/64 | | | | aea6ea63-b70c-49fe-9bf5-3f593015a07d 172.24.4.0/24 | | 1931775c-4459-4c18-9910-53b1ffbe4d31 | private | 9b1a99a3-e7ae-4a7d-b9d2-e035077d4e5e 10.0.0.0/24 | | | | 3ebaa37a-2b80-4186-9357-dd8b1202d542 fd7e:7e2b:56d0::/64 | +--+-+--+ 3.we can create instance with these network by using command. 4.check devstack dashboard gui. I find that we can't display private network. only public network is listed on the network column. but in admin column, we can see networks are all there. when try to launch a instance, we only can see network named public
[Yahoo-eng-team] [Bug 1528397] [NEW] Style: Material Design: Alerts should have a box-shadow
Public bug reported: Material Design is ALL about a stack of 3-D elements, so the upper toasts in the corner should really reflect that. ** Affects: horizon Importance: Undecided Assignee: Diana Whitten (hurgleburgler) Status: New ** Changed in: horizon Assignee: (unassigned) => Diana Whitten (hurgleburgler) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1528397 Title: Style: Material Design: Alerts should have a box-shadow Status in OpenStack Dashboard (Horizon): New Bug description: Material Design is ALL about a stack of 3-D elements, so the upper toasts in the corner should really reflect that. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1528397/+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 1528393] [NEW] signature_utils tests fail on Fedora/RHEL/CentOS because not all ECC curves are available
Public bug reported: Not all ECC curves we use in signature_utils are available on all platforms - e.g. On RHEL 7.2 $ openssl ecparam -list_curves secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field On Fedora 23 ... $ openssl ecparam -list_curves secp256k1 : SECG curve over a 256 bit prime field secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field There's a long history surrounding the lack of ECC support in openssl in Fedora, RHEL, and CentOS because of legal issues - see https://bugzilla.redhat.com/show_bug.cgi?id=319901 Some ECC curves are now available, but each additional one requested will be considered individually - there is a tracker bug for this: https://bugzilla.redhat.com/showdependencytree.cgi?id=1019390&hide_resolved=0 This is the failure I'm seeing since https://review.openstack.org/#/c/256069/ was merged nova.tests.unit.test_signature_utils.TestSignatureUtils.test_verify_signature_ECC - Captured traceback: ~~~ Traceback (most recent call last): File "/home/markmc/git/openstack/nova/.tox/py27/lib/python2.7/site-packages/mock/mock.py", line 1305, in patched return func(*args, **keywargs) File "nova/tests/unit/test_signature_utils.py", line 178, in test_verify_signature_ECC default_backend()) File "/home/markmc/git/openstack/nova/.tox/py27/lib/python2.7/site-packages/cryptography/hazmat/primitives/asymmetric/ec.py", line 241, in generate_private_key return backend.generate_elliptic_curve_private_key(curve) File "/home/markmc/git/openstack/nova/.tox/py27/lib/python2.7/site-packages/cryptography/hazmat/backends/multibackend.py", line 247, in generate_elliptic_curve_private_key _Reasons.UNSUPPORTED_ELLIPTIC_CURVE cryptography.exceptions.UnsupportedAlgorithm: This backend does not support this elliptic curve. ** Affects: nova Importance: Undecided Assignee: Mark McLoughlin (markmc) 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/1528393 Title: signature_utils tests fail on Fedora/RHEL/CentOS because not all ECC curves are available Status in OpenStack Compute (nova): In Progress Bug description: Not all ECC curves we use in signature_utils are available on all platforms - e.g. On RHEL 7.2 $ openssl ecparam -list_curves secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field On Fedora 23 ... $ openssl ecparam -list_curves secp256k1 : SECG curve over a 256 bit prime field secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field There's a long history surrounding the lack of ECC support in openssl in Fedora, RHEL, and CentOS because of legal issues - see https://bugzilla.redhat.com/show_bug.cgi?id=319901 Some ECC curves are now available, but each additional one requested will be considered individually - there is a tracker bug for this: https://bugzilla.redhat.com/showdependencytree.cgi?id=1019390&hide_resolved=0 This is the failure I'm seeing since https://review.openstack.org/#/c/256069/ was merged nova.tests.unit.test_signature_utils.TestSignatureUtils.test_verify_signature_ECC - Captured traceback: ~~~ Traceback (most recent call last): File "/home/markmc/git/openstack/nova/.tox/py27/lib/python2.7/site-packages/mock/mock.py", line 1305, in patched return func(*args, **keywargs) File "nova/tests/unit/test_signature_utils.py", line 178, in test_verify_signature_ECC default_backend()) File "/home/markmc/git/openstack/nova/.tox/py27/lib/python2.7/site-packages/cryptography/hazmat/primitives/asymmetric/ec.py", line 241, in generate_private_key return backend.generate_elliptic_curve_private_key(curve) File "/home/markmc/git/openstack/nova/.tox/py27/lib/python2.7/site-packages/cryptography/hazmat/backends/multibackend.py", line 247, in generate_elliptic_curve_private_key _Reasons.UNSUPPORTED_ELLIPTIC_CURVE cryptography.exceptions.UnsupportedAlgorithm: This backend does not support this elliptic curve. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1528393/+subscriptions -- Mailing list: https://launch
[Yahoo-eng-team] [Bug 1527719] Re: Adding a VNIC type for physical functions
** Also affects: openstack-api-site Importance: Undecided Status: New ** Changed in: openstack-api-site Assignee: (unassigned) => Atsushi SAKAI (sakaia) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1527719 Title: Adding a VNIC type for physical functions Status in neutron: Fix Released Status in openstack-api-site: New Status in openstack-manuals: New Bug description: https://review.openstack.org/246923 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 2c60278992d5a21724105ed0ca6e1d2f3e5c Author: Brent Eagles Date: Mon Nov 9 09:26:53 2015 -0330 Adding a VNIC type for physical functions This change adds a new VNIC type to distinguish between virtual and physical functions in SR-IOV. The new VNIC type 'direct-physical' deviates from the behavior of 'direct' VNICs for virtual functions. While neutron tracks the resource as a port, it does not currently perform any management functions. Future changes may extend the segment mapping functionality that is currently based on agent configuration to include direct types. However, the direct-physical VNICs will not have functional parity with the other SR-IOV VNIC types in that quality of service and port security functionality is not available. APIImpact DocImpact: Add description for new 'direct-physical' VNIC type. Closes-Bug: #1500993 Change-Id: If1ab969c2002c649a3d51635ca2765c262e2d37f To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1527719/+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 1528382] [NEW] default theme's warning color is not readable
Public bug reported: Its far too light: https://www.dropbox.com/s/f6cl12jfdxd4llr/Screenshot%202015-12-21%2016.26.48.png?dl=0 ** Affects: horizon Importance: Undecided Assignee: Diana Whitten (hurgleburgler) Status: In Progress ** Changed in: horizon Assignee: (unassigned) => Diana Whitten (hurgleburgler) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1528382 Title: default theme's warning color is not readable Status in OpenStack Dashboard (Horizon): In Progress Bug description: Its far too light: https://www.dropbox.com/s/f6cl12jfdxd4llr/Screenshot%202015-12-21%2016.26.48.png?dl=0 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1528382/+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 1528372] [NEW] H2 should not be manually overridden
Public bug reported: H2 styles are manually set in horizon.scss This has adverse side effects to other themes: https://www.dropbox.com/s/q78kq58n4bjeo6p/Screenshot%202015-12-21%2015.36.01.png?dl=0 ** Affects: horizon Importance: Undecided Assignee: Diana Whitten (hurgleburgler) Status: New ** Changed in: horizon Assignee: (unassigned) => Diana Whitten (hurgleburgler) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1528372 Title: H2 should not be manually overridden Status in OpenStack Dashboard (Horizon): New Bug description: H2 styles are manually set in horizon.scss This has adverse side effects to other themes: https://www.dropbox.com/s/q78kq58n4bjeo6p/Screenshot%202015-12-21%2015.36.01.png?dl=0 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1528372/+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 1528369] [NEW] Theme Preview Pages should use Font Awesome
Public bug reported: Horizon converted all class='caret' to class='fa fa-caret-down'. The theme preview page should reflect this as well. ** Affects: horizon Importance: Undecided Assignee: Diana Whitten (hurgleburgler) Status: New ** Changed in: horizon Assignee: (unassigned) => Diana Whitten (hurgleburgler) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1528369 Title: Theme Preview Pages should use Font Awesome Status in OpenStack Dashboard (Horizon): New Bug description: Horizon converted all class='caret' to class='fa fa-caret-down'. The theme preview page should reflect this as well. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1528369/+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 1464259] Re: Volumes tests fails often with rbd backend
Flavio, there is a backport to stable/liberty proposed.
** Also affects: nova/liberty
Importance: Undecided
Status: New
** Changed in: nova/liberty
Status: New => In Progress
** Changed in: nova/liberty
Assignee: (unassigned) => Matt Riedemann (mriedem)
** Changed in: nova/liberty
Importance: Undecided => High
--
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/1464259
Title:
Volumes tests fails often with rbd backend
Status in Cinder:
Triaged
Status in OpenStack Compute (nova):
Fix Released
Status in OpenStack Compute (nova) liberty series:
In Progress
Status in tempest:
Invalid
Bug description:
http://logs.openstack.org/02/173802/5/check/check-tempest-dsvm-full-
ceph/a72aac1/logs/screen-n-api.txt.gz?level=TRACE#_2015-06-11_09_04_19_511
2015-06-11 09:04:19.511 ERROR nova.api.ec2
[req-0ac81d78-2717-4dd2-80e2-d94363b55ac8 EC2VolumesTest-442487008
EC2VolumesTest-1066393631] Unexpected InvalidInput raised: Invalid input
received: Invalid volume: Volume still has 1 dependent snapshots. (HTTP 400)
(Request-ID: req-4586b5d2-7212-4ddd-af79-43ad8ba7ea58)
2015-06-11 09:04:19.511 ERROR nova.api.ec2
[req-0ac81d78-2717-4dd2-80e2-d94363b55ac8 EC2VolumesTest-442487008
EC2VolumesTest-1066393631] Environment: {"HTTP_AUTHORIZATION":
"AWS4-HMAC-SHA256
Credential=a5e9253350ce4a249ddce8b7c1c798c2/20150611/0/127/aws4_request,SignedHeaders=host;x-amz-date,Signature=304830ed947f7fba3143887b08d1e47faa18d4b59782c0992727cb7593f586b4",
"SCRIPT_NAME": "", "REQUEST_METHOD": "POST", "HTTP_X_AMZ_DATE":
"20150611T090418Z", "PATH_INFO": "/", "SERVER_PROTOCOL": "HTTP/1.0",
"CONTENT_LENGTH": "60", "HTTP_USER_AGENT": "Boto/2.38.0 Python/2.7.6
Linux/3.13.0-53-generic", "RAW_PATH_INFO": "/", "REMOTE_ADDR": "127.0.0.1",
"wsgi.url_scheme": "http", "SERVER_PORT": "8773", "CONTENT_TYPE":
"application/x-www-form-urlencoded; charset=UTF-8", "HTTP_HOST":
"127.0.0.1:8773", "SERVER_NAME": "127.0.0.1", "GATEWAY_INTERFACE": "CGI/1.1",
"REMOTE_PORT": "45819", "HTTP_ACCEPT_ENCODING": "identity"}
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRUMyVm9sdW1lc1Rlc3RcIiBBTkQgbWVzc2FnZTpcIlVuZXhwZWN0ZWQgSW52YWxpZElucHV0IHJhaXNlZDogSW52YWxpZCBpbnB1dCByZWNlaXZlZDogSW52YWxpZCB2b2x1bWU6IFZvbHVtZSBzdGlsbCBoYXMgMSBkZXBlbmRlbnQgc25hcHNob3RzXCIgQU5EIHRhZ3M6XCJzY3JlZW4tbi1hcGkudHh0XCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MzQwMzAyMTUwODd9
10 hits in 7 days, check and gate, hitting on the ceph and glusterfs
jobs.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1464259/+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 1528368] [NEW] Material Theme: Large Button has rounded corners
Public bug reported: All buttons in 'material' need to have 0 border radius: https://www.dropbox.com/s/9z27cjpua72o381/Screenshot%202015-12-21%2015.24.28.png?dl=0 ** Affects: horizon Importance: Undecided Assignee: Diana Whitten (hurgleburgler) Status: New ** Changed in: horizon Assignee: (unassigned) => Diana Whitten (hurgleburgler) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1528368 Title: Material Theme: Large Button has rounded corners Status in OpenStack Dashboard (Horizon): New Bug description: All buttons in 'material' need to have 0 border radius: https://www.dropbox.com/s/9z27cjpua72o381/Screenshot%202015-12-21%2015.24.28.png?dl=0 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1528368/+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 1528349] [NEW] Nova and Glance contain a near-identical signature_utils module
Public bug reported: It appears that https://review.openstack.org/256069 took the signature_utils modules from Glance and modified it in fairly superficial ways based on review feedback: $ diff -u nova/nova/signature_utils.py glance/glance/common/signature_utils.py | diffstat signature_utils.py | 182 - 1 file changed, 83 insertions(+), 99 deletions(-) The Oslo project was created to avoid this sort of short-sighted cut- and-pasting. This code should really be in a python library that both Glance and Nova could use directly. Perhaps the code could be moved to a new library in the Glance project, or a new library in the Oslo project, or into the cryptography library itself? ** Affects: glance Importance: Undecided Status: New ** Affects: nova Importance: Undecided Status: New ** Also affects: glance 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/1528349 Title: Nova and Glance contain a near-identical signature_utils module Status in Glance: New Status in OpenStack Compute (nova): New Bug description: It appears that https://review.openstack.org/256069 took the signature_utils modules from Glance and modified it in fairly superficial ways based on review feedback: $ diff -u nova/nova/signature_utils.py glance/glance/common/signature_utils.py | diffstat signature_utils.py | 182 - 1 file changed, 83 insertions(+), 99 deletions(-) The Oslo project was created to avoid this sort of short-sighted cut- and-pasting. This code should really be in a python library that both Glance and Nova could use directly. Perhaps the code could be moved to a new library in the Glance project, or a new library in the Oslo project, or into the cryptography library itself? To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1528349/+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 1214341] Re: Not all db.sqal.session methods are wrapped by wrap_db_error
** Changed in: cinder Status: Triaged => Fix Released ** Changed in: cinder Assignee: (unassigned) => Ivan Kolodyazhny (e0ne) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1214341 Title: Not all db.sqal.session methods are wrapped by wrap_db_error Status in Cinder: Fix Released Status in Ironic: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in oslo-incubator: Fix Released Bug description: first(), all(), begin(), commit() and other public methods could produce amount of exceptions, that should be wrapped in exception in any case. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1214341/+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 1528325] [NEW] instance with explicit "small" pages treated different from implicit
Public bug reported: In numa_get_constraints() we call pagesize = _numa_get_pagesize_constraints(flavor, image_meta) then later we have if nodes or pagesize: [setattr(c, 'pagesize', pagesize) for c in numa_topology.cells] This ends up treating an instance which doesn't specify pagesize (which results in 4K pages) differently from an instance that explicitly specifies 4K pages. In the first case the instance may not have a numa topology specified, while in the second case it does. In _get_guest_numa_config() we check whether the guest has a numa topology, and if it does we restrict it to a single NUMA node rather than letting it float across the whole host. This unexpectedly results in different CPU and memory affinity depending on whether an instance implicitly assumes 4K pages or explicitly specifies them. ** Affects: nova Importance: Undecided Status: New ** Tags: compute numa ** Summary changed: - explicit "small" pages treated different from implicit + instance with explicit "small" pages treated different from implicit -- 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/1528325 Title: instance with explicit "small" pages treated different from implicit Status in OpenStack Compute (nova): New Bug description: In numa_get_constraints() we call pagesize = _numa_get_pagesize_constraints(flavor, image_meta) then later we have if nodes or pagesize: [setattr(c, 'pagesize', pagesize) for c in numa_topology.cells] This ends up treating an instance which doesn't specify pagesize (which results in 4K pages) differently from an instance that explicitly specifies 4K pages. In the first case the instance may not have a numa topology specified, while in the second case it does. In _get_guest_numa_config() we check whether the guest has a numa topology, and if it does we restrict it to a single NUMA node rather than letting it float across the whole host. This unexpectedly results in different CPU and memory affinity depending on whether an instance implicitly assumes 4K pages or explicitly specifies them. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1528325/+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 1526660] Re: enable os-inherit by default
Reviewed: https://review.openstack.org/257580 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=5ae155a3dea38612f7f57228424f306ec9bded3c Submitter: Jenkins Branch:master commit 5ae155a3dea38612f7f57228424f306ec9bded3c Author: Ken'ichi Ohmichi Date: Mon Dec 14 22:14:40 2015 + Enable os_inherit of Keystone v3 API os_inherit extension has been implemented since 2 years ago, and the API doc[1] also contains it. However os_inherit extension is disabled on the default. So it is nice to enable the extension for productions, development and testing. This patch comes from the discussion[2]. NOTE: This patch removes a test class which tests the enabled os_inherit because os_inherit becomes enabled on the default. [1]: http://developer.openstack.org/api-ref-identity-v3-ext.html#identity_v3_OS-INHERIT-ext [2]: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081822.html Closes-Bug: 1526660 Change-Id: Ifac71f7415f21c402f6e00c5264e972b0e80388c ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1526660 Title: enable os-inherit by default Status in OpenStack Identity (keystone): Fix Released Bug description: The OS-INHERIT 'extension' has been around since Icehouse. It was always disabled by default. But with bp move-extensions bringing in all the extensions and enabling them by default, we should enable this one too. Note that OS-INHERIT does not have any database migrations, and it's code all lives in the assignment package, so there is much less work to migrate it over compared to the other extensions. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1526660/+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 1508106] Re: For wrong ethertype exception message is hard coded
Reviewed: https://review.openstack.org/258971 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=be14e905419f0927539e939c1f979430a6e44d42 Submitter: Jenkins Branch:master commit be14e905419f0927539e939c1f979430a6e44d42 Author: Sreekumar S Date: Thu Dec 17 02:34:33 2015 +0530 Corrected wrong ethertype exception message This patch resolves the issue where wrong message was being shown when ethertype input parameter was not amongst one of the types supported. New message made akin to other input parameters like 'protocol'. Change-Id: I5636f3582c9d9877dad4d091a374284b656923f4 Closes-Bug: #1508106 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1508106 Title: For wrong ethertype exception message is hard coded Status in neutron: Fix Released Bug description: if you give any wrong ethertype while creating security group rule. it will always mention reason None in exception message Invalid input for ethertype. Reason: 'None' is not in ['IPv4', 'IPv6']. try neutron security-group-rule-create --ethertype ip --protocol icmp it will print Invalid input for ethertype. Reason: 'None' is not in ['IPv4', 'IPv6']. but actually it should be Invalid input for ethertype. Reason: 'ip' is not in ['IPv4', 'IPv6']. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1508106/+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 1527113] Re: Code duplication in neutron/api/v2attribute.py
Reviewed: https://review.openstack.org/258867 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=dd5f5716c9a32634caa2a44d362cd77461ba873d Submitter: Jenkins Branch:master commit dd5f5716c9a32634caa2a44d362cd77461ba873d Author: Hong Hui Xiao Date: Thu Dec 17 03:26:56 2015 -0500 Remove duplicated code in attribute.py The _validate_XXX_list functions in [1] are mostly duplicated, this patch will use one function to validate list of items and remove others. [1] neutron/api/v2/attributes.py Change-Id: I86905018914becb64451941f0ecb06be30f2c740 Closes-Bug: #1527113 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1527113 Title: Code duplication in neutron/api/v2attribute.py Status in neutron: Fix Released Bug description: Found this when reviewing code. neutron/api/v2attribute.py may validate list of items, there are different functions to validate list of different items. The code are mostly duplicated in [1-3]. And more can be expected in future. [1] https://github.com/openstack/neutron/blob/b8d281a303ca12440aebb55895ebb192d25cecf8/neutron/api/v2/attributes.py#L121 [2] https://github.com/openstack/neutron/blob/b8d281a303ca12440aebb55895ebb192d25cecf8/neutron/api/v2/attributes.py#L350 [3] https://github.com/openstack/neutron/blob/b8d281a303ca12440aebb55895ebb192d25cecf8/neutron/api/v2/attributes.py#L411 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1527113/+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 1479838] Re: 500 error when using fernet tokens and not providing a token in the request.
*** This bug is a duplicate of bug 1526976 *** https://bugs.launchpad.net/bugs/1526976 ** This bug is no longer a duplicate of bug 1474942 Missing either X-Auth-Token or X-Subject-Token in fernet token gives HTTP 500 code. ** This bug has been marked a duplicate of bug 1526976 Any operation without token fails with internal server error for fernet token -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1479838 Title: 500 error when using fernet tokens and not providing a token in the request. Status in OpenStack Identity (keystone): In Progress Bug description: Change keystone.conf to use Fernet tokens and issue any api call. curl http://localhost:5000/v3/users/xyz This is because the token is not checked for null value in the Fernet token provider code. The fix should be straight forward though. I will create a patch for this. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1479838/+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 1508421] Re: Projects dropdown fails due to incomplete Keystone endpoint URL
Reviewed: https://review.openstack.org/238419 Committed: https://git.openstack.org/cgit/openstack/django_openstack_auth/commit/?id=58ce9d7edeac81dbd7e7f77efde33c97e8d1e00c Submitter: Jenkins Branch:master commit 58ce9d7edeac81dbd7e7f77efde33c97e8d1e00c Author: Johannes Grassler Date: Wed Oct 21 17:43:35 2015 +0200 Add API version to identity endpoint URLs This change adds the Keystone API version to the identity endpoint URL retrieved from Keystone's endpoint list. This is neccessary in Kilo and later, since identity endpoint URLs retrieved from Keystone no longer contain the API version path they used to contain until Juno. See https://bugs.launchpad.net/horizon/+bug/1508421 for a detailed analysis of the problem. Change-Id: Ieff5a6cdd1ad352a9731d46785802e8c36adcdd1 Closes-Bug: 1508421 ** Changed in: django-openstack-auth Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1508421 Title: Projects dropdown fails due to incomplete Keystone endpoint URL Status in django-openstack-auth: Fix Released Status in OpenStack Dashboard (Horizon): In Progress Bug description: Problem Description === The 'Projects' dropdown in our Horizon dashboard (the one on the top left) is empty since we switched to Openstack Kilo. We investigated the issue and found the following error message in horizon.log: AuthorizationFailure: Authorization Failed: The resource could not be found. (HTTP 404) http://10.0.81.10:5000 [You will find a full stack trace in stacktrace.txt in the attached tarball.] Further investigation (see keystone.pcap in the attached tarball for a packet trace) revealed that horizon is trying to access http://10.0.81.10:5000/tokens (as opposed to the correct URL, http://10.0.81.10:5000/v2.0/tokens). We found the problem could be worked around by appending missing versioning information in backend.py (see below), but it should be possible to fix this in a cleaner manner. Environment === We are running Openstack Kilo with the Ubuntu Cloud packages, some of them modified locally with backported bugfixes. You will find these packages at https://launchpad.net/~syseleven-platform/+archive/ubuntu/kilo. In particular, we are running the following Horizon package: https://launchpad.net/~syseleven-platform/+archive/ubuntu/kilo Configuration = You will find our full Horizon configuration in local_settings.py in the attached tarball. Relevant points: * OPENSTACK_KEYSTONE_URL is http://10.0.81.10:5000/v2.0 * OPENSTACK_API_VERSIONS is configured for Keystone 2.0 * The identity endpoints as reported by Keystone itself do not contain versioning information (the way it is supposed to be as of Kilo). Steps to reproduce == * Run Horizon/Kilo (with the Ubuntu Cloud packages or our modified packages; both should exhibit this problem) * Configure the end points and OPENSTACK_KEYSTONE_URL as described under "Configuration" * Log into the web interface. This should yield an empty Projects dropdown list and the stacktrace in stacktrace.txt in /var/log/horizon/horizon.log). Workaround == I modified /usr/lib/python2.7/dist-packages/openstack_auth/backend.py to append versioning information to the endpoint URL if it is missing. This can be used to work around the problem in a pinch, but I do not consider it a clean fix. Files = I attached a couple of files to illustrate the problem (you will find all of these in horizon-projects-dropdown.tar): backend.py The modified backend.py described under "Workaround" endpoints.txt A list of identity endpoints as reported by Keystone keystone.pcap A packet capture of Horizon's interactions with Keystone local_settings.py Our Horizon configuration stacktrace.txt The stack trace that appears in /var/log/horizon/horizon.log To manage notifications about this bug go to: https://bugs.launchpad.net/django-openstack-auth/+bug/1508421/+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 1528267] [NEW] There is an error "NoSuchMethod: Endpoint does not support RPC method add_shard_cluster" when add a shard to mongodb cluster
Public bug reported: When i add a shard to mongodb cluster. The trove-taskmanager has an error. The error message is as follow. 2015-12-21 23:44:33.225 16857 ERROR oslo_messaging.rpc.dispatcher [-] Exception during message handling: Endpoint does not support RPC method add_shard_cluster 2015-12-21 23:44:33.225 16857 ERROR oslo_messaging.rpc.dispatcher Traceback (most recent call last): 2015-12-21 23:44:33.225 16857 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 142, in _dispatch_and_reply 2015-12-21 23:44:33.225 16857 ERROR oslo_messaging.rpc.dispatcher executor_callback)) 2015-12-21 23:44:33.225 16857 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 193, in _dispatch 2015-12-21 23:44:33.225 16857 ERROR oslo_messaging.rpc.dispatcher raise NoSuchMethod(method) 2015-12-21 23:44:33.225 16857 ERROR oslo_messaging.rpc.dispatcher NoSuchMethod: Endpoint does not support RPC method add_shard_cluster ** Affects: keystone Importance: Undecided Assignee: alex (chinabjalex) Status: New ** Changed in: keystone Assignee: (unassigned) => alex (chinabjalex) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1528267 Title: There is an error "NoSuchMethod: Endpoint does not support RPC method add_shard_cluster" when add a shard to mongodb cluster Status in OpenStack Identity (keystone): New Bug description: When i add a shard to mongodb cluster. The trove-taskmanager has an error. The error message is as follow. 2015-12-21 23:44:33.225 16857 ERROR oslo_messaging.rpc.dispatcher [-] Exception during message handling: Endpoint does not support RPC method add_shard_cluster 2015-12-21 23:44:33.225 16857 ERROR oslo_messaging.rpc.dispatcher Traceback (most recent call last): 2015-12-21 23:44:33.225 16857 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 142, in _dispatch_and_reply 2015-12-21 23:44:33.225 16857 ERROR oslo_messaging.rpc.dispatcher executor_callback)) 2015-12-21 23:44:33.225 16857 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 193, in _dispatch 2015-12-21 23:44:33.225 16857 ERROR oslo_messaging.rpc.dispatcher raise NoSuchMethod(method) 2015-12-21 23:44:33.225 16857 ERROR oslo_messaging.rpc.dispatcher NoSuchMethod: Endpoint does not support RPC method add_shard_cluster To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1528267/+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 1528266] [NEW] Enable secure_proxy_ssl_header by default in keystone.conf
*** This bug is a duplicate of bug 1528258 *** https://bugs.launchpad.net/bugs/1528258 Public bug reported: Currently, keystone.conf has a option named secure_proxy_ssl_header which set to None by default. I suppose it should be set to HTTP_X_FORWARDED_PROTO by default, as X-Forwarded-Proto is a default header for this. Also, this doesn't break anything by default, as if this header will be unset - code related to it will be never used. Today 2 steps should be done if we have SSL terminator before keystone - we should configure keystone special way for this and also configure terminator some special way. It leads to troubles, misunderstanding how keystone works and false-positive bug reports, so much nicer would be have this option enabled by default. ** Affects: keystone Importance: Undecided Status: New ** This bug has been marked a duplicate of bug 1528258 secure_proxy_ssl_header should default to HTTP_X_FORWARDED_PROTO -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1528266 Title: Enable secure_proxy_ssl_header by default in keystone.conf Status in OpenStack Identity (keystone): New Bug description: Currently, keystone.conf has a option named secure_proxy_ssl_header which set to None by default. I suppose it should be set to HTTP_X_FORWARDED_PROTO by default, as X-Forwarded-Proto is a default header for this. Also, this doesn't break anything by default, as if this header will be unset - code related to it will be never used. Today 2 steps should be done if we have SSL terminator before keystone - we should configure keystone special way for this and also configure terminator some special way. It leads to troubles, misunderstanding how keystone works and false-positive bug reports, so much nicer would be have this option enabled by default. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1528266/+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 1528258] [NEW] secure_proxy_ssl_header should default to HTTP_X_FORWARDED_PROTO
Public bug reported: https://bugs.launchpad.net/keystone/+bug/1370022 resulted in https://review.openstack.org/132235 which added secure_proxy_ssl_header option being added to keystone. It works if it's correctly set, but there is no valid reason why you would not want to enable this feature by default. It adds an extra burden to configuration managers when there's exactly 1 ideal default value (even specified in the comment for the option). I propose that we have default/secure_proxy_ssl_header = "HTTP_X_FORWARDED_PROTO" instead of default/secure_proxy_ssl_header = instated as default in the package. ** Affects: keystone Importance: Undecided Assignee: Boris Bobrov (bbobrov) Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1528258 Title: secure_proxy_ssl_header should default to HTTP_X_FORWARDED_PROTO Status in OpenStack Identity (keystone): New Bug description: https://bugs.launchpad.net/keystone/+bug/1370022 resulted in https://review.openstack.org/132235 which added secure_proxy_ssl_header option being added to keystone. It works if it's correctly set, but there is no valid reason why you would not want to enable this feature by default. It adds an extra burden to configuration managers when there's exactly 1 ideal default value (even specified in the comment for the option). I propose that we have default/secure_proxy_ssl_header = "HTTP_X_FORWARDED_PROTO" instead of default/secure_proxy_ssl_header = instated as default in the package. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1528258/+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 1526244] Re: Able to create objects by admin in the particular domain, for incorrect domain Id field name "domain-id".
According to VMT taxonomy, this is a class E.
** Changed in: ossa
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1526244
Title:
Able to create objects by admin in the particular domain, for
incorrect domain Id field name "domain-id".
Status in OpenStack Identity (keystone):
In Progress
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
Admin is able to create objects(user,group,.) in a particular domain,
though field name is misspelt as "domain-id" instead of "domain_id".
Step Followed: User creation by admin with incorrect field name
"domain-id"
ubuntu@ubuntu:~$ curl -i -k -X POST -H "Content-Type: application/json" -H
"X-AUTH-TOKEN:ae5ed453cf444969953850532cb9b581" /v3/users -d '{
> "user":
> {
> "name":"User Pwr Ranger 50",
> "password":"pwd",
> "description":"User Creation in another domain",
> "domain-id":"37a09709db404e7d97f8a211ebebc93f"
> }
> }'
HTTP/1.1 201 Created
Date: Fri, 13 Nov 2015 12:38:22 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
x-openstack-request-id: req-1cc05a23-065f-4a25-9fcd-90fa827722d3
Content-Length: 290
Content-Type: application/json
{"user": {"links": {"self":
"/v3/users/90776556002948dfb44227aef3b042e7"},
"description": "User Creation in another domain", "name": "User Pwr
Ranger 50", "enabled": true, "id": "90776556002948dfb44227aef3b042e7",
"domain_id": "37a09709db404e7d97f8a211ebebc93f"}}
The user got created in a specified domain "domain-
id":"37a09709db404e7d97f8a211ebebc93f", even though domain Id field is
misspelt as "domain-id" instead of "domain_id".
Hence the issue has to be resolved by creating objects in "default"
domain when the field name is spelt wrongly.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1526244/+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 1528250] [NEW] Wrong string format in exception FlavorExtraSpecUpdateCreateFailed
Public bug reported:
class FlavorExtraSpecUpdateCreateFailed(NovaException):
msg_fmt = _("Flavor %(id)d extra spec cannot be updated or created "
"after %(retries)d retries.")
'id' here means 'flavorid' which is String (not Integer).
** Affects: nova
Importance: Low
Assignee: Pavel Kholkin (pkholkin)
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/1528250
Title:
Wrong string format in exception FlavorExtraSpecUpdateCreateFailed
Status in OpenStack Compute (nova):
In Progress
Bug description:
class FlavorExtraSpecUpdateCreateFailed(NovaException):
msg_fmt = _("Flavor %(id)d extra spec cannot be updated or created "
"after %(retries)d retries.")
'id' here means 'flavorid' which is String (not Integer).
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1528250/+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 1528235] [NEW] [REF]Add weight to l3 agent
Public bug reported: [Existing problem] Currently, neutron will treat all l3 agent as the same. The default LeastRoutersScheduler will chose l3 agent, based on the load of l3 agents. But the hosts of l3 agents may be different. Some hosts may have better CPU, larger memory and better network bandwidth. Admins/Operators may want the host with higher performance to take more load. [Proposal] Add a configuration to l3_agent.ini to represent the weight of l3 agent. Admins/Operators can set higher weight to the l3 agent with higher performance. The l3 agent with higher weight will have higher chance to be selected by the L3Scheduler. [Benefits] Neutron can provide a better scheduling by leveraging the difference of performance of l3 agents' hosts [What is the enhancement?] Configuration file changes. Code change in the L3 scheduler. ** Affects: neutron Importance: Undecided Assignee: Hong Hui Xiao (xiaohhui) Status: New ** Tags: rfe ** Tags added: rfe ** Changed in: neutron Assignee: (unassigned) => Hong Hui Xiao (xiaohhui) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1528235 Title: [REF]Add weight to l3 agent Status in neutron: New Bug description: [Existing problem] Currently, neutron will treat all l3 agent as the same. The default LeastRoutersScheduler will chose l3 agent, based on the load of l3 agents. But the hosts of l3 agents may be different. Some hosts may have better CPU, larger memory and better network bandwidth. Admins/Operators may want the host with higher performance to take more load. [Proposal] Add a configuration to l3_agent.ini to represent the weight of l3 agent. Admins/Operators can set higher weight to the l3 agent with higher performance. The l3 agent with higher weight will have higher chance to be selected by the L3Scheduler. [Benefits] Neutron can provide a better scheduling by leveraging the difference of performance of l3 agents' hosts [What is the enhancement?] Configuration file changes. Code change in the L3 scheduler. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1528235/+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 1520618] Re: lb agent: dhcp tap not plugged in bridge with vlan setup
Reviewed: https://review.openstack.org/253067 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=cac2436f298491dbca2c932c80bdf3a64ac39ee6 Submitter: Jenkins Branch:master commit cac2436f298491dbca2c932c80bdf3a64ac39ee6 Author: Andreas Scheuring Date: Thu Dec 3 14:54:39 2015 +0100 Correct return values for bridge sysctl calls This fixes an issue where the lb agent did not plug the dhcp tap device into the bridge when having vlan networking set up. Caused by setting of disable_ipv6 value. Closes-Bug: #1520618 Change-Id: I0d21fad3a676d1fdd30501ea6a295f1e9b207a3a Co-Authored-By: Brian Haley ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1520618 Title: lb agent: dhcp tap not plugged in bridge with vlan setup Status in neutron: Fix Released Bug description: Commit [1] disables ipv6 on linuxbridges. On my linuxbridge vlan system, this fix causes the code ensure_bridge() to return too early without passing the bridge_name back. The introduced method returns the output of the systcl -w call +def disable_ipv6(self): +cmd = 'net.ipv6.conf.%s.disable_ipv6=1' % self.name +return self._sysctl([cmd]) The sysctl always outputs the config that has been set (at least on my ubuntu): # sudo sysctl -w net.ipv6.conf.brq1192ca0d-a3.disable_ipv6=1 net.ipv6.conf.brq1192ca0d-a3.disable_ipv6 = 1 The check that has been introduced assumes that on successful executing, nothing (or return code 0) is returned - but the command always returns something! +if bridge_device.disable_ipv6(): +return The result is, that the tap device of the dhcp server is not plugged into the bridge but instead still loosely hanging around. Log from a lb tempest run [1]. after the sysctl command is executed, the method returns (the follow on call that sets the bridge up is missing): 2015-11-26 14:45:36.283 DEBUG neutron.agent.linux.utils [req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Exit code: 0 execute /opt/stack/new/neutron/neutron/agent/linux/utils.py:142 2015-11-26 14:45:36.284 DEBUG neutron.agent.linux.utils [req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Running command (rootwrap daemon): ['sysctl', '-w', 'net.ipv6.conf.brq66379423-07.disable_ipv6=1'] execute_rootwrap_daemon /opt/stack/new/neutron/neutron/agent/linux/utils.py:100 2015-11-26 14:45:36.286 DEBUG neutron.agent.linux.utils [req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Exit code: 0 execute /opt/stack/new/neutron/neutron/agent/linux/utils.py:142 2015-11-26 14:45:36.286 DEBUG neutron.agent.linux.utils [req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Running command: ['ip', '-o', 'link', 'show', 'vxlan-1009'] create_process /opt/stack/new/neutron/neutron/agent/linux/utils.py:84 2015-11-26 14:45:36.294 DEBUG neutron.agent.linux.utils [req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Exit code: 0 execute /opt/stack/new/neutron/neutron/agent/linux/utils.py:142 2015-11-26 14:45:36.295 DEBUG neutron.agent.linux.utils [req-0655a18f-ce22-445c-834b-96ba4c91ae6e None None] Running command (rootwrap daemon): ['ip', 'link', 'set', 'tap35e6a6a9-ef', 'mtu', '1450'] execute_rootwrap_daemon [1] https://review.openstack.org/#/c/241076/ [2] http://logs.openstack.org/85/193485/21/check/gate-tempest-dsvm-neutron-linuxbridge/7341e9a/logs/screen-q-agt.txt.gz To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1520618/+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 1525137] Re: doc wrong about BAK extensions of injection
Reviewed: https://review.openstack.org/256351 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=326de7607a4a2d9b99fc1f7cf6005bba5b6a06f6 Submitter: Jenkins Branch:master commit 326de7607a4a2d9b99fc1f7cf6005bba5b6a06f6 Author: jichenjc Date: Fri Dec 11 04:11:27 2015 +0800 Remove incorrect comments about file injection there is no method on 'BAK extension appended with a time stamp' if this comes from some Active engine, we should let active engine to document it instead of generialize it in nova blueprint complete-todo-in-api-concept-doc Closes-Bug: 1525137 Change-Id: Ibb05dc57f9be81de335ca4935c4c7fa59971de13 ** Changed in: nova Status: In Progress => Fix Released -- 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/1525137 Title: doc wrong about BAK extensions of injection Status in OpenStack Compute (nova): Fix Released Status in openstack-api-site: Fix Released Bug description: I cat following contents into a.pwd , note the '1' at /bin/sh1 of ssh line it's on purpose after following opreations, I didn't see fllowing mechanism talked in doc For example, if the /etc/passwd file exists, it is backed up as /etc/passwd.bak.1246036261.5785. https://github.com/openstack/nova/blob/master/api-guide/source/server_concepts.rst http://developer.openstack.org/api-ref-compute-v2.1.html $ sudo cat passwd root:x:0:0:root:/root:/bin/sh daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:100:sync:/bin:/bin/sync mail:x:8:8:mail:/var/spool/mail:/bin/sh proxy:x:13:13:proxy:/bin:/bin/sh www-data:x:33:33:www-data:/var/www:/bin/sh backup:x:34:34:backup:/var/backups:/bin/sh operator:x:37:37:Operator:/var:/bin/sh haldaemon:x:68:68:hald:/:/bin/sh dbus:x:81:81:dbus:/var/run/dbus:/bin/sh ftp:x:83:83:ftp:/home/ftp:/bin/sh nobody:x:99:99:nobody:/home:/bin/sh sshd:x:103:99:Operator:/var:/bin/sh1 cirros:x:1000:1000:non-root user:/home/cirros:/bin/sh do the following jichen@devstack1:/opt/stack/nova$ nova boot --file /etc/passwd=/home/jichen/a.pwd --image 9eee793a-25e5-4f42-bd9e-b869e60d3dbd --flavor m1.micro t6 +--++ | Property | Value | +--++ | OS-DCF:diskConfig| MANUAL | | OS-EXT-AZ:availability_zone | | | OS-EXT-STS:power_state | 0 | | OS-EXT-STS:task_state| scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | - | | OS-SRV-USG:terminated_at | - | | accessIPv4 | | | accessIPv6 | | | adminPass| 9VUVZY53nbFb | | config_drive | | | created | 2015-12-11T09:19:28Z | | flavor | m1.micro (84) | | hostId | | | id | 80f24559-2bd9-4709-b1a2-36709cfb3b50 | | image| cirros-0.3.4-x86_64-uec (9eee793a-25e5-4f42-bd9e-b869e60d3dbd) | jichen@devstack1:/opt/stack/nova$ ssh cirros@10.0.0.17 The authenticity of host '10.0.0.17 (10.0.0.17)' can't be established. RSA key fingerprint is c2:44:7a:4f:61:cb:1b:95:b4:3a:49:fe:ce:dc:1e:20. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.0.0.17' (RSA) to the list of known hosts. cirros@10.0.0.17's password: $ cd /etc $ ls TZ cirros fstab init.d ld.so.conf mtab profileresolv.confshadow acpi cirros-initgroup initt
[Yahoo-eng-team] [Bug 1523780] Re: Race between HA router create and HA router delete
The following exceptions are not fixed:
1.DBReferenceError: (IntegrityError)
2. AttributeError: 'NoneType' object has no attribute 'config' (l3 agent
process router in router_delete function)
3. DBError: UPDATE statement on table 'ports' expected to update 1
row(s); 0 were matched. (Maybe this patch
https://review.openstack.org/#/c/238122/ can fix this.)
4. res = {"id": port["id"],
TypeError: 'NoneType' object is unsubscriptable
** Changed in: neutron
Status: Fix Released => 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/1523780
Title:
Race between HA router create and HA router delete
Status in neutron:
In Progress
Bug description:
Set more than one API worker and RPC worker, and then run rally scenario
test create_and_delete_routers:
you may get such errors:
1.DBReferenceError: (IntegrityError) (1452, 'Cannot add or update a
child row: a foreign key constraint fails
(`neutron`.`ha_router_agent_port_bindings`, CONSTRAINT
`ha_router_agent_port_bindings_ibfk_2` FOREIGN KEY (`router_id`)
REFERENCES `routers` (`id`) ON DELETE CASCADE)') 'INSERT INTO
ha_router_agent_port_bindings (port_id, router_id, l3_agent_id, state)
VALUES (%s, %s, %s, %s)' ('xxx', 'xxx', None,
'standby')
(InvalidRequestError: This Session's transaction has been rolled back
by a nested rollback() call. To begin a new transaction, issue
Session.rollback() first.)
2. AttributeError: 'NoneType' object has no attribute 'config' (l3
agent process router in router_delete function)
3. DBError: UPDATE statement on table 'ports' expected to update 1
row(s); 0 were matched.
4. res = {"id": port["id"],
TypeError: 'NoneType' object is unsubscriptable
5. delete HA network during deleting the last router, get error
message: "Unable to complete operation on network . There
are one or more ports still in use on the network."
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1523780/+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 1528137] [NEW] creating meter label rule doesn't work properly
Public bug reported: Created rule by the following API counts packets between a router which connects to external network and the connection destination device. API: POST /v2.0/metering/metering-label-rules When outbound traffic of external router, destination should be remote_ip, and when inbound traffic, sender should be remote_ip. But it has become actually reversed. Because option for creating the iptables rule is reversed. code: https://github.com/openstack/neutron/blob/master/neutron/services/metering/drivers/iptables/iptables_driver.py#L176 I'll show you an example that created the meter label rule the remote_ip is set to 192.168.0.0/16. [Actual results] $ neutron meter-label-create test-label --tenant-id 2a023bd32f014e44b60b591cbd151514 Created a new metering_label: +-+--+ | Field | Value| +-+--+ | description | | | id | d35d0464-f872-43c7-8dd8-850657da59ef | | name| test-label | | shared | False| | tenant_id | 2a023bd32f014e44b60b591cbd151514 | +-+--+ $ neutron meter-label-create test-label2 --tenant-id 2a023bd32f014e44b60b591cbd151514 Created a new metering_label: +-+--+ | Field | Value| +-+--+ | description | | | id | 61c344ce-0438-4cd3-bbd8-a4d5e0dbce6f | | name| test-label2 | | shared | False| | tenant_id | 2a023bd32f014e44b60b591cbd151514 | +-+--+ $ neutron meter-label-rule-create --tenant-id 2a023bd32f014e44b60b591cbd151514 --direction egress d35d0464-f872-43c7-8dd8-850657da59ef 192.168.0.0/16 $ neutron meter-label-rule-create --tenant-id 2a023bd32f014e44b60b591cbd151514 --direction ingress 61c344ce-0438-4cd3-bbd8-a4d5e0dbce6f 192.168.0.0/16 $ neutron meter-label-rule-list +--+--+---+--+ | id | excluded | direction | remote_ip_prefix | +--+--+---+--+ | 3e426537-61f4-44ac-a67a-e66ce26dc11b | False| egress| 192.168.0.0/16 | | 4d669406-173c-4eea-af21-00430719cbfa | False| ingress | 192.168.0.0/16 | +--+--+---+--+ $ sudo ip netns exec qrouter-b72b789e-8ca9-465e-a2d1-98f725a7042f iptables-save ... -A neutron-meter-r-61c344ce-043 -d 192.168.0.0/16 -i qg-708e8abf-bc -j neutron-meter-l-61c344ce-043 -A neutron-meter-r-d35d0464-f87 -s 192.168.0.0/16 -o qg-708e8abf-bc -j neutron-meter-l-d35d0464-f87 ... [The expected iptables rules] -A neutron-meter-r-61c344ce-043 -s 192.168.0.0/16 -i qg-708e8abf-bc -j neutron-meter-l-61c344ce-043 -A neutron-meter-r-d35d0464-f87 -d 192.168.0.0/16 -o qg-708e8abf-bc -j neutron-meter-l-d35d0464-f87 [Examples of required packet is not counted] ubuntu@test-vm(10.0.0.3):~$ ping 192.168.0.3 -c 3 PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data. 64 bytes from 192.168.0.3: icmp_seq=1 ttl=62 time=1.13 ms 64 bytes from 192.168.0.3: icmp_seq=2 ttl=62 time=0.618 ms 64 bytes from 192.168.0.3: icmp_seq=3 ttl=62 time=0.652 ms --- 192.168.0.3 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.618/0.801/1.133/0.235 ms $ sudo ip netns exec qrouter-b72b789e-8ca9-465e-a2d1-98f725a7042f iptables -t filter -L neutron-meter-l-d35d0464-f87 -n -v -x Chain neutron-meter-l-d35d0464-f87 (2 references) pkts bytes target prot opt in out source destination 00all -- * * 0.0.0.0/0 0.0.0.0/0 ** 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/1528137 Title: creating meter label rule doesn't work properly Status in neutron: New Bug description: Created rule by the following API counts packets between a router which connects to external network and the connection destination device. API: POST /v2.0/metering/metering-label-rules When outbound traffic of external router, destination should be remote_ip, and when inbound traffic, sender should be remote_ip. But it has become actually reversed. Because option for creating the iptables rule is reversed. code: https://github.com/openstack/neutron/blob/master/neutron/services/metering/drivers/iptables/iptables_driver.py#L176
