[Yahoo-eng-team] [Bug 1311804] Re: ip netns list starts without root_helper
** Changed in: fuel/4.1.x
Status: New => Invalid
** Changed in: fuel
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/1311804
Title:
ip netns list starts without root_helper
Status in Fuel: OpenStack installer that works:
Invalid
Status in Fuel for OpenStack 4.1.x series:
Invalid
Status in OpenStack Neutron (virtual network service):
Invalid
Bug description:
CENTOS 6.5
Reproduced on typical Openstack installation in any segmentation type with
one L3-agent.
In ip_lib in IpNetnsComand losted root_helper.
Without it L3 agent can't create interfaces inside network namespace, because
in Centos 'ip netns list' returns empty list if start without root privileges.
[root@node-2 ~]# uname -a
Linux node-2.domain.tld 2.6.32-431.11.2.el6.x86_64 #1 SMP Tue Mar 25 19:59:55
UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@node-2 ~]# ip netns list
haproxy
qrouter-b582586e-70e3-4a38-8b19-039f30ce87a9
[root@node-2 ~]# su -m neutron -c 'ip netns list'
[root@node-2 ~]#
in the log below exception happens because namespace already exists
(see full log in attach), but can't detected by ip netns list without
root_wrapper.
2014-04-23 16:15:44.760 28240 DEBUG neutron.agent.linux.utils
[req-d0f812f6-d987-45f5-9cff-11f1fa52fed6 None] Running command: ['ip', '-o',
'netns', 'list'] create_process /
usr/lib/python2.6/site-packages/neutron/agent/linux/utils.py:48
2014-04-23 16:15:44.781 28240 DEBUG neutron.agent.linux.utils
[req-d0f812f6-d987-45f5-9cff-11f1fa52fed6 None]
Command: ['ip', '-o', 'netns', 'list']
Exit code: 0
Stdout: ''
Stderr: '' execute
/usr/lib/python2.6/site-packages/neutron/agent/linux/utils.py:74
2014-04-23 16:15:44.782 28240 DEBUG neutron.agent.linux.utils
[req-d0f812f6-d987-45f5-9cff-11f1fa52fed6 None] Running command: ['sudo',
'neutron-rootwrap', '/etc/neutron/roo
twrap.conf', 'ip', 'netns', 'add',
'qrouter-b582586e-70e3-4a38-8b19-039f30ce87a9'] create_process
/usr/lib/python2.6/site-packages/neutron/agent/linux/utils.py:48
2014-04-23 16:15:44.864 28240 DEBUG neutron.agent.linux.utils
[req-d0f812f6-d987-45f5-9cff-11f1fa52fed6 None]
Command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip',
'netns', 'add', 'qrouter-b582586e-70e3-4a38-8b19-039f30ce87a9']
Exit code: 255
Stdout: ''
Stderr: 'Could not create
/var/run/netns/qrouter-b582586e-70e3-4a38-8b19-039f30ce87a9: File exists\n'
execute /usr/lib/python2.6/site-packages/neutron/agent/linux/utils.py:7
4
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/eventlet/greenpool.py", line 80, in
_spawn_n_impl
func(*args, **kwargs)
File "/usr/lib/python2.6/site-packages/neutron/agent/l3_agent.py", line
438, in process_router
p['ip_cidr'], p['mac_address'])
File "/usr/lib/python2.6/site-packages/neutron/agent/l3_agent.py", line
707, in internal_network_added
prefix=INTERNAL_DEV_PREFIX)
File "/usr/lib/python2.6/site-packages/neutron/agent/linux/interface.py",
line 195, in plug
namespace_obj = ip.ensure_namespace(namespace)
File "/usr/lib/python2.6/site-packages/neutron/agent/linux/ip_lib.py", line
136, in ensure_namespace
ip = self.netns.add(name)
File "/usr/lib/python2.6/site-packages/neutron/agent/linux/ip_lib.py", line
446, in add
self._as_root('add', name, use_root_namespace=True)
File "/usr/lib/python2.6/site-packages/neutron/agent/linux/ip_lib.py", line
217, in _as_root
kwargs.get('use_root_namespace', False))
File "/usr/lib/python2.6/site-packages/neutron/agent/linux/ip_lib.py", line
70, in _as_root
namespace)
File "/usr/lib/python2.6/site-packages/neutron/agent/linux/ip_lib.py", line
81, in _execute
root_helper=root_helper)
File "/usr/lib/python2.6/site-packages/neutron/agent/linux/utils.py", line
76, in execute
raise RuntimeError(m)
RuntimeError:
Command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip',
'netns', 'add', 'qrouter-b582586e-70e3-4a38-8b19-039f30ce87a9']
Exit code: 255
To manage notifications about this bug go to:
https://bugs.launchpad.net/fuel/+bug/1311804/+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 1320655] Re: UnicodeDecodeError in the nova gate logs
** 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/1320655 Title: UnicodeDecodeError in the nova gate logs Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Compute (Nova): Confirmed Bug description: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOiBcIlVuaWNvZGVEZWNvZGVFcnJvclwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDAwNDI3ODM3NzE0LCJtb2RlIjoiIiwiYW5hbHl6ZV9maWVsZCI6IiJ9 message: "UnicodeDecodeError" Looks like the n-cpu tries to long something not unicide. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1320655/+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 1330856] [NEW] Confusing fault reasion when the flavors disk size was too small
Public bug reported:
Fedora-x86_64-20-20140407-sda has 2 GiB virtual size.
$ nova boot fed_1G_2 --image Fedora-x86_64-20-20140407-sda --flavor 1
--key-name mykey
$ nova show fed_1G_2
+--+--+
| Property | Value
|
+--+--+
| OS-DCF:diskConfig| MANUAL
|
| OS-EXT-AZ:availability_zone | nova
|
| OS-EXT-STS:power_state | 0
|
| OS-EXT-STS:task_state| -
|
| OS-EXT-STS:vm_state | error
|
| OS-SRV-USG:launched_at | -
|
| OS-SRV-USG:terminated_at | -
|
| accessIPv4 |
|
| accessIPv6 |
|
| config_drive |
|
| created | 2014-06-17T07:35:43Z
|
| fault| {"message": "No valid host was found.
", "code": 500, "created": "2014-06-17T07:35:44Z"} |
| flavor | m1.tiny (1)
|
| hostId |
a904a292f4eb7f6735bef786c4a240a0b9240a6bc4f002519cb0e2b7
|
| id | 3c908a54-9682-40ad-8f12-a5bf6400
|
| image| Fedora-x86_64-20-20140407-sda
(085610a8-77ae-4bc8-9a28-3bcc1020e06e) |
| key_name | mykey
|
| metadata | {}
|
| name | fed_1G_2
|
| os-extended-volumes:volumes_attached | []
|
| private network | 10.1.0.5
|
| security_groups | default
|
| status | ERROR
|
| tenant_id| 1d26ad7003cf47e5b0107313be4832c3
|
| updated | 2014-06-17T07:35:44Z
|
| user_id | bf52e56b9ca14648b391c5b6d490a0c1
|
+--+--+
$ # nova flavor-list
+-+---+---+--+---+-+---+-+---+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap_MB | VCPUs |
RXTX_Factor | Is_Public |
+-+---+---+--+---+-+---+-+---+
| 1 | m1.tiny | 512 | 1| 0 | | 1 | 1.0
| True |
| 2 | m1.small | 2048 | 20 | 0 | | 1 | 1.0
| True |
| 3 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0
| True |
| 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0
| True |
| 42 | m1.nano | 64| 0| 0 | | 1 | 1.0
| True |
| 451 | m1.heat | 1024 | 0
[Yahoo-eng-team] [Bug 1330873] [NEW] Instance name set in horizon is not set in VMware vCenter
Public bug reported: Instance name set in horizon is not set in VMware vCenter. In vCenter the name of the instance is the id (in UUID format) of the instance. This makes it difficult for the administrator to locate the instance in vCenter using the name displayed in horizon. ** Affects: nova Importance: Undecided Assignee: Kiran Kumar Vaddi (kiran-kumar-vaddi) Status: New ** Tags: vmware ** Changed in: nova Assignee: (unassigned) => Kiran Kumar Vaddi (kiran-kumar-vaddi) -- 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/1330873 Title: Instance name set in horizon is not set in VMware vCenter Status in OpenStack Compute (Nova): New Bug description: Instance name set in horizon is not set in VMware vCenter. In vCenter the name of the instance is the id (in UUID format) of the instance. This makes it difficult for the administrator to locate the instance in vCenter using the name displayed in horizon. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1330873/+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 1330896] [NEW] firewall rule should not be allowed to create with same source ip and destination ip
Public bug reported: DESCRIPTION: firewall rule should not be allowed to create with same source and destination ip Steps to Reproduce: root@IGA-OSC:~# neutron firewall-rule-create --protocol icmp --name r2 --source-ip-address 10.10.10.1 --destination-ip-address 10.10.10.1 --action allow \Created a new firewall_rule: ++--+ | Field | Value| ++--+ | action | allow| | description| | | destination_ip_address | 10.10.10.1 | | destination_port | | | enabled| True | | firewall_policy_id | | | id | 1f5a0176-6ce3-4987-8c6b-e986be602a79 | | ip_version | 4| | name | r2 | | position | | | protocol | icmp | | shared | False| | source_ip_address | 10.10.10.1 | | source_port| | | tenant_id | 0ad385e00e97476e9456945c079a21ea | ++--+ ** Affects: neutron Importance: Undecided Assignee: Koteswara Rao Kelam (koti-kelam) Status: New ** Changed in: neutron Assignee: (unassigned) => Koteswara Rao Kelam (koti-kelam) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1330896 Title: firewall rule should not be allowed to create with same source ip and destination ip Status in OpenStack Neutron (virtual network service): New Bug description: DESCRIPTION: firewall rule should not be allowed to create with same source and destination ip Steps to Reproduce: root@IGA-OSC:~# neutron firewall-rule-create --protocol icmp --name r2 --source-ip-address 10.10.10.1 --destination-ip-address 10.10.10.1 --action allow \Created a new firewall_rule: ++--+ | Field | Value| ++--+ | action | allow| | description| | | destination_ip_address | 10.10.10.1 | | destination_port | | | enabled| True | | firewall_policy_id | | | id | 1f5a0176-6ce3-4987-8c6b-e986be602a79 | | ip_version | 4| | name | r2 | | position | | | protocol | icmp | | shared | False| | source_ip_address | 10.10.10.1 | | source_port| | | tenant_id | 0ad385e00e97476e9456945c079a21ea | ++--+ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1330896/+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 1330898] [NEW] fwaas: " firewall policy insert firewall rule " cli should not accept the same firewall rule which is going to insert in the insert-before/after field
Public bug reported: DESCRIPTION: neutron firewall-policy-insert-firewall-rule cli should not accept the same firewall rule which is going to insert in the insert-before/after field Steps to Reproduce: 1. create a firewall rule r1 2. create a firewall policy and insert r1 in to the firewall policy 3. create a firwall rule r2 and insert in to firewall policy specifuing inser before and insert after option as r2 itself Actual Results: r2 is attached in the firewall policy with out throwing any error root@IGA-OSC:~# fwpi p1 --firewall-rule r4 --insert-before r4 --insert-after r4 Inserted firewall rule in firewall policy p1 root@IGA-OSC:~# fwpl +--+--++ | id | name | firewall_rules | +--+--++ | 8648869f-5494-41e7-99de-6cc4f9247ac8 | p1 | [0aabafe1-3a3e-42e0-bb55-53a4aa11015e, | | | | 3115e8c4-936e-402b-948d-48c9fe0d8ddd, | | | | 3593c12f-4475-4aad-8fa0-e446f8f36ecc, | | | | f45fd19a-8b7a-42cd-ad90-0e0942498528] | +--+--++ root@IGA-OSC:~# fwpr p1 --firewall-rule r4 Removed firewall rule from firewall policy p1 root@IGA-OSC:~# fwpi p1 --firewall-rule r4 --insert-before r4 --insert-after r2 Inserted firewall rule in firewall policy p1 root@IGA-OSC:~# fwpl +--+--++ | id | name | firewall_rules | +--+--++ | 8648869f-5494-41e7-99de-6cc4f9247ac8 | p1 | [0aabafe1-3a3e-42e0-bb55-53a4aa11015e, | | | | 3115e8c4-936e-402b-948d-48c9fe0d8ddd, | | | | 3593c12f-4475-4aad-8fa0-e446f8f36ecc, | | | | f45fd19a-8b7a-42cd-ad90-0e0942498528] | +--+--++ root@IGA-OSC:~# fwrs r4 ++--+ | Field | Value| ++--+ | action | deny | | description| | | destination_ip_address | | | destination_port | | | enabled| True | | firewall_policy_id | 8648869f-5494-41e7-99de-6cc4f9247ac8 | | id | 0aabafe1-3a3e-42e0-bb55-53a4aa11015e | | ip_version | 4| | name | r4 | | position | 1| | protocol | icmp | | shared | False| | source_ip_address | | | source_port| | | tenant_id | d9481c57a11c46eea62886938b5378a7 | ++--+ Expected Results: It should throw error since r2 is no where attached in the firewall policy ** Affects: neutron Importance: Undecided Assignee: Koteswara Rao Kelam (koti-kelam) Status: New ** Changed in: neutron Assignee: (unassigned) => Koteswara Rao Kelam (koti-kelam) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1330898 Title: fwaas: " firewall policy insert firewall rule " cli should not accept the same firewall rule which is going to insert in the insert- before/after field Status in OpenStack Neutron (virtual network service): New Bug description: DESCRIPTION: neutron firewall-policy-insert-firewall-rule cli should not accept the same firewall rule which is going to insert in the insert-before/after field Steps to Reproduce: 1. create a firewall rule r1 2. create a firewall policy and insert r1 in to the firewall policy 3. create a firwall rule r2 and insert in to firewall policy specifuing inser before and insert after option as r2 itself Actual Results: r2 is attached in the firewall policy with out throwing any error root@IGA-OSC:~# fwpi p1 --firewall-rule r4 --insert-before r4 --insert-after r4 Inserted firewall rule in firewall policy p1 root@IGA-OSC:~# fwpl
[Yahoo-eng-team] [Bug 1330913] [NEW] fwaas: After deleting all routers or interfaces firewall status should not show as active
Public bug reported: After deleting all routers firewall status should not show as active >From Admin tenant as well as user tenant, Firewall becomes active as per the >below steps 1. create firewall (after creating firewall rule and policy) 2. create router 3. Add at least one network interface to the router 4. firewall becomes active However from admin tenant, if we create router and then firewall , firewall becomes active without the need of adding any network interface to the router . but in this sequence of firewall creation, firewall becomes active in user tenant only after adding any interface to the router. In both the above cases, firewall doesn't become inactive or down when deleting all the interfaces in the router or deleting all the router Steps to Reproduce: 1. create firewall rule and attach it to the newly created firewall policy 2. create firewall with the above policy. 3. create router and attach any network interface 4. firewall becomes active 5. remove the network interface from router or delete the router Actual Results: firewall status shows as active Expected results: firewall status should show as DOWN root@IGA-OSC:~# rid r1 55088e59-ad2b-4691-9a2f-85aa540a5743 Removed interface from router r1. root@IGA-OSC:~# rid r1 fb8b1745-8be8-44a9-bf94-15dad4cd6c1d Removed interface from router r1. root@IGA-OSC:~# rd r1 Deleted router: r1 root@IGA-OSC:~# fws f1 ++--+ | Field | Value| ++--+ | admin_state_up | True | | description| | | firewall_policy_id | 9db0f412-0e35-4786-bd9e-9f28a6de9b3e | | id | 6422127f-cc81-4f37-a5d2-f6d1ae5cc035 | | name | f1 | | status | ACTIVE | | tenant_id | d9481c57a11c46eea62886938b5378a7 | ++--+ root@IGA-OSC:~# neutron router-list ** Affects: neutron Importance: Undecided Status: New ** Tags: fwaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1330913 Title: fwaas: After deleting all routers or interfaces firewall status should not show as active Status in OpenStack Neutron (virtual network service): New Bug description: After deleting all routers firewall status should not show as active From Admin tenant as well as user tenant, Firewall becomes active as per the below steps 1. create firewall (after creating firewall rule and policy) 2. create router 3. Add at least one network interface to the router 4. firewall becomes active However from admin tenant, if we create router and then firewall , firewall becomes active without the need of adding any network interface to the router . but in this sequence of firewall creation, firewall becomes active in user tenant only after adding any interface to the router. In both the above cases, firewall doesn't become inactive or down when deleting all the interfaces in the router or deleting all the router Steps to Reproduce: 1. create firewall rule and attach it to the newly created firewall policy 2. create firewall with the above policy. 3. create router and attach any network interface 4. firewall becomes active 5. remove the network interface from router or delete the router Actual Results: firewall status shows as active Expected results: firewall status should show as DOWN root@IGA-OSC:~# rid r1 55088e59-ad2b-4691-9a2f-85aa540a5743 Removed interface from router r1. root@IGA-OSC:~# rid r1 fb8b1745-8be8-44a9-bf94-15dad4cd6c1d Removed interface from router r1. root@IGA-OSC:~# rd r1 Deleted router: r1 root@IGA-OSC:~# fws f1 ++--+ | Field | Value| ++--+ | admin_state_up | True | | description| | | firewall_policy_id | 9db0f412-0e35-4786-bd9e-9f28a6de9b3e | | id | 6422127f-cc81-4f37-a5d2-f6d1ae5cc035 | | name | f1 | | status | ACTIVE | | tenant_id | d9481c57a11c46eea62886938b5378a7 | ++--+ root@IGA-OSC:~# neutron router-list To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1330913/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://laun
[Yahoo-eng-team] [Bug 1330925] [NEW] Create bulk rpc method for update_device_up and update_device_down
Public bug reported: Something similar to what was done for get_device_details should be done for update_device_up and update_device_down. That is being able to set multiple devices down or up using one rpc call ** Affects: neutron Importance: Undecided Assignee: Rossella Sblendido (rossella-o) Status: New ** Changed in: neutron Assignee: (unassigned) => Rossella Sblendido (rossella-o) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1330925 Title: Create bulk rpc method for update_device_up and update_device_down Status in OpenStack Neutron (virtual network service): New Bug description: Something similar to what was done for get_device_details should be done for update_device_up and update_device_down. That is being able to set multiple devices down or up using one rpc call To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1330925/+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 1330924] [NEW] create a method to get all devices details in one shot
Public bug reported: There's an rpc call that allows to get the details of multiple devices at one shot. See https://review.openstack.org/#/c/66899 . There's should be a method on the plugin side to minimize the access to the db and instead of issuing a select for every port, select all the ports at once ** Affects: neutron Importance: Undecided Assignee: Rossella Sblendido (rossella-o) Status: New ** Changed in: neutron Assignee: (unassigned) => Rossella Sblendido (rossella-o) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1330924 Title: create a method to get all devices details in one shot Status in OpenStack Neutron (virtual network service): New Bug description: There's an rpc call that allows to get the details of multiple devices at one shot. See https://review.openstack.org/#/c/66899 . There's should be a method on the plugin side to minimize the access to the db and instead of issuing a select for every port, select all the ports at once To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1330924/+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 1330771] Re: pbr as run time requirement conflicts with distro packaging
Is this an issue with PBR or how we're using it? ** Changed in: keystone Status: New => Incomplete ** Also affects: pbr Importance: Undecided Status: New ** Changed in: pbr Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1330771 Title: pbr as run time requirement conflicts with distro packaging Status in OpenStack Identity (Keystone): Incomplete Status in Python Build Reasonableness: Incomplete Bug description: Using PBR for development makes sense, but it should not be a run time requirement for keystone-all or the other tools. All it is doing is reporting the version of the python library, and that does not require any of the rest of PBR. However, PBR pulls in tools that are rightfully build time requirements. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1330771/+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 1330955] [NEW] Lock wait timeout exceeded while updating status for floatingips
Public bug reported:
Lock timeout occurred when updating floating IP.
2014-06-15 12:50:41.052 15781 TRACE neutron.openstack.common.rpc.amqp
OperationalError: (OperationalError) (1205, 'Lock wait timeout exceeded;
try restarting transaction') 'UPDATE floatingips SET status=%s WHERE
floatingips.id = %s' ('ACTIVE', 'a030bb1e-31f0-42d7-84fc-520856f0ee66')
This is probably introduced in Icehouse with:
https://review.openstack.org/#/c/66866/
More info at Red Hat bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1109577
** 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/1330955
Title:
Lock wait timeout exceeded while updating status for floatingips
Status in OpenStack Neutron (virtual network service):
New
Bug description:
Lock timeout occurred when updating floating IP.
2014-06-15 12:50:41.052 15781 TRACE neutron.openstack.common.rpc.amqp
OperationalError: (OperationalError) (1205, 'Lock wait timeout
exceeded; try restarting transaction') 'UPDATE floatingips SET
status=%s WHERE floatingips.id = %s' ('ACTIVE', 'a030bb1e-31f0-42d7
-84fc-520856f0ee66')
This is probably introduced in Icehouse with:
https://review.openstack.org/#/c/66866/
More info at Red Hat bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1109577
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1330955/+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 1330958] [NEW] FakeDriver.get_available_resource is not postgresql compliant
Public bug reported:
The compute FakeDriver.get_available_resource method raises an error on
Postgres (cf stacktrace #1 at the end).
hypervisor_version is not converted in int value (correctly done in __init__).
Stacktrace #1:
ERROR nova.openstack.common.threadgroup [-] Remote error: DBError (DataError)
invalid input syntax for integer: "1.0"
LINE 1: ...=1028, hypervisor_type='fake', hypervisor_version='1.0', fre...
^
'UPDATE compute_nodes SET updated_at=%(updated_at)s, memory_mb=%(memory_mb)s,
local_gb=%(local_gb)s, hypervisor_type=%(hypervisor_type)s,
hypervisor_version=%(hypervisor_version)s, free_ram_mb=%(free_ram_mb)s,
free_disk_gb=%(free_disk_gb)s, cpu_info=%(cpu_info)s,
disk_available_least=%(disk_available_least)s,
supported_instances=%(supported_instances)s WHERE compute_nodes.id =
%(compute_nodes_id)s' {'supported_instances': u'[[null, "fake", null]]',
'hypervisor_type': u'fake', 'updated_at': datetime.datetime(2014, 6, 17, 11,
52, 34, 778314), 'memory_mb': 8192, 'cpu_info': u'?', 'free_disk_gb': 1028,
'compute_nodes_id': 4, 'hypervisor_version': u'1.0', 'disk_available_least': 0,
'local_gb': 1028, 'free_ram_mb': 7680}
[u'Traceback (most recent call last):\n', u' File
"/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 133,
in _dispatch_and_reply\nincoming.message))\n', u' File
"/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 176,
in _dispatch\nreturn self._do_dispatch(endpoint, method, ctxt, args)\n', u'
File "/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line
122, in _do_dispatch\nresult = getattr(endpoint, method)(ctxt,
**new_args)\n', u' File
"/usr/lib/python2.7/dist-packages/nova/conductor/manager.py", line 980, in
compute_node_update\nreturn self.manager.compute_node_update(context, node,
values)\n', u' File
"/usr/lib/python2.7/dist-packages/nova/conductor/manager.py", line 482, in
compute_node_update\nresult = self.db.compute_node_update(context,
node[\'id\'], values)\n', u' File
"/usr/lib/python2.7/dist-packages/nova/db/api.py", line 233, in
compute_node_update\nreturn IMPL.compute_node_update
(context, compute_id, values)\n', u' File
"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py", line 146, in
wrapper\nreturn f(*args, **kwargs)\n', u' File
"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py", line 202, in
wrapped\nreturn f(*args, **kwargs)\n', u' File
"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py", line 652, in
compute_node_update\ncompute_ref.update(values)\n', u' File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 447, in
__exit__\nself.rollback()\n', u' File
"/usr/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py", line 58, in
__exit__\ncompat.reraise(exc_type, exc_value, exc_tb)\n', u' File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 444, in
__exit__\nself.commit()\n', u' File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 354, in
commit\nself._prepare_impl()\n', u' File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/sessio
n.py", line 334, in _prepare_impl\nself.session.flush()\n', u' File
"/usr/lib/python2.7/dist-packages/nova/openstack/common/db/sqlalchemy/session.py",
line 460, in _wrap\nraise exception.DBError(e)\n', u'DBError: (DataError)
invalid input syntax for integer: "1.0"\nLINE 1: ...=1028,
hypervisor_type=\'fake\', hypervisor_version=\'1.0\', fre...\n
^\n \'UPDATE compute_nodes SET
updated_at=%(updated_at)s, memory_mb=%(memory_mb)s, local_gb=%(local_gb)s,
hypervisor_type=%(hypervisor_type)s, hypervisor_version=%(hypervisor_version)s,
free_ram_mb=%(free_ram_mb)s, free_disk_gb=%(free_disk_gb)s,
cpu_info=%(cpu_info)s, disk_available_least=%(disk_available_least)s,
supported_instances=%(supported_instances)s WHERE compute_nodes.id =
%(compute_nodes_id)s\' {\'supported_instances\': u\'[[null, "fake", null]]\',
\'hypervisor_type\': u\'fake\', \'updated_at\': datetime.datetime(2014, 6, 17,
11, 52, 34, 778314), \'memory_mb\': 819
2, \'cpu_info\': u\'?\', \'free_disk_gb\': 1028, \'compute_nodes_id\': 4,
\'hypervisor_version\': u\'1.0\', \'disk_available_least\': 0, \'local_gb\':
1028, \'free_ram_mb\': 7680}\n'].
hypervisor_version
** Affects: nova
Importance: Undecided
Assignee: Gregory Cunha (gregory-cunha)
Status: In Progress
** Tags: compute icehouse-backport-potential
** Changed in: nova
Assignee: (unassigned) => Gregory Cunha (gregory-cunha)
** Changed in: nova
Status: New => 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/1330958
Title:
FakeDriver.get_available_resour
[Yahoo-eng-team] [Bug 1329884] Re: Conflicting documention on V3 Identity roles route
** Project changed: openstack-manuals => openstack-api-site
** Also affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1329884
Title:
Conflicting documention on V3 Identity roles route
Status in OpenStack Identity (Keystone):
New
Status in OpenStack API documentation site:
New
Bug description:
http://developer.openstack.org/api-ref-identity-v3.html documents a
/v3/users/{user_id}/roles route but https://github.com/openstack
/identity-api/blob/master/v3/src/markdown/identity-api-v3.md has no
mention of such a route.
When I've tried to access the /v3/users/{user_id}/roles route using
V3 Identity I get a 404, although I can access domain and project role
routes ok. I'm not certain if I'm doing something wrong or if this
route doesn't actually exist.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1329884/+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 1260439] Re: Error message when creating a user with the default member role
** Also affects: horizon/icehouse Importance: Undecided Status: New ** Changed in: horizon/icehouse Status: New => In Progress ** Changed in: horizon/icehouse Importance: Undecided => Medium ** Changed in: horizon/icehouse Assignee: (unassigned) => Matthias Runge (mrunge) -- 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/1260439 Title: Error message when creating a user with the default member role Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) icehouse series: In Progress Bug description: When you create a new user with the same role, from the roles list, as the default member role set in keystone.conf, Horizon shows the error message "Unable to add user to primary project". Even with this message, the user is created and the member role is granted to the user in the selected project. If you look the keystone.log file, you will see the following warning: " WARNING keystone.common.wsgi [-] Conflict occurred attempting to store role grant. User already has role in tenant " Example: I have the "member_role_name = _member_" entry in my keystone.conf file. When I create a User called "Test_User" in the project "Test_Project" with the role "_member_", the error message is shown. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1260439/+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 1329884] Re: Conflicting documention on V3 Identity roles route
This shouldn't affect keystone, as we neither specify nor implement this
resource.
The apparently equivalent call that we do implement is:
GET /v3/role_assignments?user.id={user_id}
https://github.com/openstack/identity-api/blob/master/v3/src/markdown
/identity-api-v3.md#list-effective-role-assignments-get-role_assignments
** Changed in: keystone
Status: New => Invalid
** Changed in: openstack-api-site
Status: New => Confirmed
** Tags added: identity-api
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1329884
Title:
Conflicting documention on V3 Identity roles route
Status in OpenStack Identity (Keystone):
Invalid
Status in OpenStack API documentation site:
Confirmed
Bug description:
http://developer.openstack.org/api-ref-identity-v3.html documents a
/v3/users/{user_id}/roles route but https://github.com/openstack
/identity-api/blob/master/v3/src/markdown/identity-api-v3.md has no
mention of such a route.
When I've tried to access the /v3/users/{user_id}/roles route using
V3 Identity I get a 404, although I can access domain and project role
routes ok. I'm not certain if I'm doing something wrong or if this
route doesn't actually exist.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1329884/+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 1182131] Re: nova-compute: instance created in self-referencing secgroup produces KeyError
As pointed out in the bug description, this doesn't appear to cause issues. The logstash query proves that, there is still a 94% success rate on the job when this shows up. ** No longer affects: nova/folsom -- 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/1182131 Title: nova-compute: instance created in self-referencing secgroup produces KeyError Status in OpenStack Compute (Nova): Confirmed Bug description: Hi, Steps to reproduce: 1) create a security group that is referencing itself, for example euca-create-group test2 euca-authorize test2 -P tcp -p 22 -s 0.0.0.0/0 euca-authorize test2 -P tcp -p -o test2 2) create any instance in this security group euca-run-instance .. -g test2 .. Expected result: no stackstrace to be thrown Actual result: stacktrace with KeyError appears in the log. The iptable rules are created correctly and instance ends up in running state. File "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 390, in refresh_instance_security_rules return self.driver.refresh_instance_security_rules(instance) File "/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py", line 2269, in refresh_instance_security_rules self.firewall_driver.refresh_instance_security_rules(instance) File "/usr/lib/python2.6/site-packages/nova/virt/firewall.py", line 440, in refresh_instance_security_rules self.do_refresh_instance_rules(instance) File "/usr/lib/python2.6/site-packages/nova/virt/firewall.py", line 457, in do_refresh_instance_rules network_info = self.network_infos[instance['id']] KeyError: 4168 It seems that self.network_infos is accessed in wrong order for the security group that is referencing itself. The stacktrace is from 'do_refresh_instance_rules' which expects network info to be already present for the instance that is being created. Reported KeyError is the id of newly created instance. The dictionary entry is added few seconds later processing the same request. Fortunately, this issue does not appear to have any negative impact aside the stacktrace in the log. Openstack version: Folsom 2012.2.4 Attaching verbose log from nova-compute. Regards, Brano Zarnovican To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1182131/+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 1330993] [NEW] L3-Agent does not process some router update messages due to missing thread synchronization
Public bug reported:
The L3-Agent does not process some router update messages due to the
updates being overwritten due to missing thread synchronization. This
happens when a lot of FloatingIP and Router APIs are invoked.
The functions _rpc_loop and _sync_routers_task are annotated with
@lockutils.synchronized('l3-agent', 'neutron-'). This provides
concurrent access to the global variables updated_routers and
removed_routers.
However the same variables would be updated by the RPC methods such as
routers_updated, router_deleted etc.
As a temporary fix these methods could also be made synchronized, but
investigation is needed about a minor redesign to avoid using the global
variables to keep track of any updates.
** 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/1330993
Title:
L3-Agent does not process some router update messages due to missing
thread synchronization
Status in OpenStack Neutron (virtual network service):
New
Bug description:
The L3-Agent does not process some router update messages due to the
updates being overwritten due to missing thread synchronization. This
happens when a lot of FloatingIP and Router APIs are invoked.
The functions _rpc_loop and _sync_routers_task are annotated with
@lockutils.synchronized('l3-agent', 'neutron-'). This provides
concurrent access to the global variables updated_routers and
removed_routers.
However the same variables would be updated by the RPC methods such as
routers_updated, router_deleted etc.
As a temporary fix these methods could also be made synchronized, but
investigation is needed about a minor redesign to avoid using the
global variables to keep track of any updates.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1330993/+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 1330981] [NEW] Cannot attach volumes to LXC instances
Public bug reported: Volumes cannot be attach to any LXC instances since it's root device cannot be parsed properly. This later causes a failure in device name generation in get_next_device_name(), when attempting to generate a name for the attached volume. The generated device name, will not be recognized by get_dev_prefix_for_disk_bus() when trying to select a disk bus, nor libvirt will be able to attach the volume with an unrecognized device name. When creating a LXC instance, the /dev/nbd1 or /dev/loop0 devices will be saved as instance root device in _create_domain() Later, when attaching the volume, block_device.match_device will be called from compute_utils.get_next_device_name(), The formed device will be named as /dev/na (for /dev/nbdX) Which will not be recognized in blockinfo.get_dev_prefix_for_disk_bus() Even if it will be recognized, libvirt wont be able to attach a volume named /dev/na ** Affects: nova Importance: Undecided Assignee: Vladik Romanovsky (vladik-romanovsky) Status: New ** Tags: libvirt lxc ** Tags added: lxc ** Tags added: libvirt ** Changed in: nova Assignee: (unassigned) => Vladik Romanovsky (vladik-romanovsky) -- 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/1330981 Title: Cannot attach volumes to LXC instances Status in OpenStack Compute (Nova): New Bug description: Volumes cannot be attach to any LXC instances since it's root device cannot be parsed properly. This later causes a failure in device name generation in get_next_device_name(), when attempting to generate a name for the attached volume. The generated device name, will not be recognized by get_dev_prefix_for_disk_bus() when trying to select a disk bus, nor libvirt will be able to attach the volume with an unrecognized device name. When creating a LXC instance, the /dev/nbd1 or /dev/loop0 devices will be saved as instance root device in _create_domain() Later, when attaching the volume, block_device.match_device will be called from compute_utils.get_next_device_name(), The formed device will be named as /dev/na (for /dev/nbdX) Which will not be recognized in blockinfo.get_dev_prefix_for_disk_bus() Even if it will be recognized, libvirt wont be able to attach a volume named /dev/na To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1330981/+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 1329884] Re: Conflicting documention on V3 Identity roles route
** No longer affects: keystone
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1329884
Title:
Conflicting documention on V3 Identity roles route
Status in OpenStack API documentation site:
Confirmed
Bug description:
http://developer.openstack.org/api-ref-identity-v3.html documents a
/v3/users/{user_id}/roles route but https://github.com/openstack
/identity-api/blob/master/v3/src/markdown/identity-api-v3.md has no
mention of such a route.
When I've tried to access the /v3/users/{user_id}/roles route using
V3 Identity I get a 404, although I can access domain and project role
routes ok. I'm not certain if I'm doing something wrong or if this
route doesn't actually exist.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-api-site/+bug/1329884/+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 1331020] [NEW] Interface status is not updated automatically
Public bug reported: Steps to reproduce: 1. Create network. 2. Create router. 3. Add netowrk interface to router (a. Navigate to router details page b. click "Add Interface" c. use network created in p.1) Actual Result: Interface status on router details page is "DOWN" until I manually refresh page. Expected result: Interface status on router details page should be automatically updated (due to consistency with other elenments statuses in horizon). ** Affects: horizon Importance: Undecided Status: New ** Description changed: Steps to reproduce: 1. Create network. 2. Create router. 3. Add netowrk interface to router (a. Navigate to router details page b. click "Add Interface" c. use network created in p.1) Actual Result: - Interface status on router details page is "DOWN" until I manually refresh page. + Interface status on router details page is "DOWN" until I manually refresh page. Expected result: - Interface status on roter details page should be automatically updated (due to consistency with other elenments statuses in horizon). + Interface status on router details page should be automatically updated (due to consistency with other elenments statuses in horizon). -- 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/1331020 Title: Interface status is not updated automatically Status in OpenStack Dashboard (Horizon): New Bug description: Steps to reproduce: 1. Create network. 2. Create router. 3. Add netowrk interface to router (a. Navigate to router details page b. click "Add Interface" c. use network created in p.1) Actual Result: Interface status on router details page is "DOWN" until I manually refresh page. Expected result: Interface status on router details page should be automatically updated (due to consistency with other elenments statuses in horizon). To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1331020/+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 1330771] Re: pbr as run time requirement conflicts with distro packaging
** Changed in: keystone Status: Incomplete => Invalid ** Changed in: pbr Status: Incomplete => New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1330771 Title: pbr as run time requirement conflicts with distro packaging Status in OpenStack Identity (Keystone): Invalid Status in Python Build Reasonableness: New Bug description: Using PBR for development makes sense, but it should not be a run time requirement for keystone-all or the other tools. All it is doing is reporting the version of the python library, and that does not require any of the rest of PBR. However, PBR pulls in tools that are rightfully build time requirements. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1330771/+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 1331032] [NEW] Network agent tab in admin should check supported exception
Public bug reported: Some neutron plugin don't support agent extension. However, network agent tab don't check agent extension is supported or not. https://github.com/openstack/horizon/blob/6c0ab78c1781ca8f58b11ac6a9a23c14176d6fb3/openstack_dashboard/dashboards/admin/info/tabs.py#L87 We should add check here using api.neutron.is_extension_supported method. ** 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/1331032 Title: Network agent tab in admin should check supported exception Status in OpenStack Dashboard (Horizon): New Bug description: Some neutron plugin don't support agent extension. However, network agent tab don't check agent extension is supported or not. https://github.com/openstack/horizon/blob/6c0ab78c1781ca8f58b11ac6a9a23c14176d6fb3/openstack_dashboard/dashboards/admin/info/tabs.py#L87 We should add check here using api.neutron.is_extension_supported method. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1331032/+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 1325725] Re: tempest doesn't have integration testing on nova's quota-class API
** No longer affects: tempest -- 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/1325725 Title: tempest doesn't have integration testing on nova's quota-class API Status in OpenStack Dashboard (Horizon): Confirmed Bug description: Related: https://bugs.launchpad.net/horizon/+bug/1292589 Nova shouldn't have been able to remove that functionality if horizon was using it. So we have a gap in testing the APIs that horizon is using. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1325725/+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 1209007] Re: aggregate metadata doesn't have availability_zone key
*** This bug is a duplicate of bug 1252177 *** https://bugs.launchpad.net/bugs/1252177 ** This bug has been marked a duplicate of bug 1252177 The argument availability_zone of create aggregate should be optional -- 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/1209007 Title: aggregate metadata doesn't have availability_zone key Status in OpenStack Compute (Nova): Confirmed Bug description: The failure found in this log: http://logs.openstack.org/23/39723/11/check/gate-tempest-devstack-vm- testr-full/ea37975/console.html which was reported in bug 1208627 was caused by a key error raised in add_host_to_aggregate() The underlying error that raised the KeyError was: 2013-08-05 18:59:04.332 18531 TRACE nova.api.openstack File "/opt/stack/new/nova/nova/compute/api.py", line 3060, in add_host_to_aggregate 2013-08-05 18:59:04.332 18531 TRACE nova.api.openstack aggregate_az = aggregate_meta["availability_zone"].pop() 2013-08-05 18:59:04.332 18531 TRACE nova.api.openstack KeyError: 'availability_zone' see https://review.openstack.org/#/c/40265/ log testr run n-api log: http://logs.openstack.org/65/40265/1/check/gate-tempest-devstack-vm- testr-full/58da4df/logs/screen-n-api.txt.gz However, when an aggregate is created an availability_zone field is required. So there shouldn't be a case where there isn't an availability_zone key in the database. (if an aggregate isn't an availability_zone the key's value should be None). So there is probably a db race or something else going on below nova.compute.api.add_host_to_aggregate(). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1209007/+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 1316475] Re: [SRU] CloudSigma DS for causes hangs when serial console present
** Changed in: tripleo Status: Triaged => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1316475 Title: [SRU] CloudSigma DS for causes hangs when serial console present Status in Init scripts for use on cloud images: Fix Committed Status in Openstack disk image builder: Fix Released Status in tripleo - openstack on openstack: Invalid Status in “cloud-init” package in Ubuntu: Fix Released Status in “cloud-init” source package in Trusty: Triaged Bug description: SRU Justification Impact: The Cloud Sigma Datasource read and writes to /dev/ttyS1 if present; the Datasource does not have a time out. On non-CloudSigma Clouds or systems w/ /dev/ttyS1, Cloud-init will block pending a response, which may never come. Further, it is dangerous for a default datasource to write blindly on a serial console as other control plane software and Clouds use /dev/ttyS1 for communication. Fix: The patch disables Cloud Sigma by default. Verification: 1. Purge Cloud-init 2. Install from -proposed 3. Look in /etc/cloud/cloud.d/90_dpkg.cfg, and confirm CloudSigma is not in the list of datasources. Regression: The risk is low, except on CloudSigma targets which try to use new images generated with the new Cloud-init version. [Original Report] DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 3 (xid=0x7e777c23) DHCPREQUEST of 10.22.157.186 on eth2 to 255.255.255.255 port 67 (xid=0x7e777c23) DHCPOFFER of 10.22.157.186 from 10.22.157.149 DHCPACK of 10.22.157.186 from 10.22.157.149 bound to 10.22.157.186 -- renewal in 39589 seconds. * Starting Mount network filesystems[ OK ] * Starting configure network device [ OK ] * Stopping Mount network filesystems[ OK ] * Stopping DHCP any connected, but unconfigured network interfaces [ OK ] * Starting configure network device [ OK ] * Stopping DHCP any connected, but unconfigured network interfaces [ OK ] * Starting configure network device [ OK ] And it stops there. I see this on about 10% of deploys. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1316475/+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 1331153] [NEW] Horizon's "API Access" UI should not show a "Download EC2 Credentials" button if EC2 is not a registered service
Public bug reported: If a service is not defined for EC2, the Access & Security -> API Access table still shows a button labeled, "Download EC2 Credentials". ** Affects: horizon Importance: Undecided Assignee: Ryan Petrello (ryan-petrello) Status: In Progress -- 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/1331153 Title: Horizon's "API Access" UI should not show a "Download EC2 Credentials" button if EC2 is not a registered service Status in OpenStack Dashboard (Horizon): In Progress Bug description: If a service is not defined for EC2, the Access & Security -> API Access table still shows a button labeled, "Download EC2 Credentials". To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1331153/+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 1331160] [NEW] "UnexpectedTaskStateError: Unexpected task state: expecting [None] but the actual state is powering-off" when running tempest.api.compute.v3.images.test_images.Ima
Public bug reported: 2014-06-17 14:02:28.274 ERROR nova.api.openstack [req-511f6615-0e70-4dee-b926-65cdd07f2653 ImagesV3Test-873712061 ImagesV3Test-286613536] Caught error: Unexpected task state: expecting [None] but the actual state is powering-off 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack Traceback (most recent call last): 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/opt/stack/new/nova/nova/api/openstack/__init__.py", line 125, in __call__ 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack return req.get_response(self.application) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1320, in send 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack application, catch_exc_info=False) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1284, in call_application 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack app_iter = application(self.environ, start_response) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack return resp(environ, start_response) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py", line 659, in __call__ 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack return self.app(env, start_response) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack return resp(environ, start_response) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack return resp(environ, start_response) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/usr/lib/python2.7/dist-packages/routes/middleware.py", line 131, in __call__ 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack response = self.app(environ, start_response) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack return resp(environ, start_response) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in __call__ 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack resp = self.call_func(req, *args, **self.kwargs) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in call_func 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack return self.func(req, *args, **kwargs) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/opt/stack/new/nova/nova/api/openstack/wsgi.py", line 917, in __call__ 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack content_type, body, accept) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/opt/stack/new/nova/nova/api/openstack/wsgi.py", line 983, in _process_stack 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack action_result = self.dispatch(meth, request, action_args) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/opt/stack/new/nova/nova/api/openstack/wsgi.py", line 1067, in dispatch 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack return method(req=request, **action_args) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/opt/stack/new/nova/nova/api/openstack/common.py", line 481, in inner 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack return f(*args, **kwargs) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/opt/stack/new/nova/nova/api/openstack/compute/plugins/v3/servers.py", line 922, in _action_create_image 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack extra_properties=props) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/opt/stack/new/nova/nova/compute/api.py", line 199, in wrapped 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack return func(self, context, target, *args, **kwargs) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/opt/stack/new/nova/nova/compute/api.py", line 216, in _wrapped 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack return fn(self, context, instance, *args, **kwargs) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack File "/opt/stack/new/nova/nova/compute/api.py", line 170, in inner 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack return f(self, context, instance, *args, **kw) 2014-06-17 14:02:28.274 14800 TRACE nova.api.openstack F
[Yahoo-eng-team] [Bug 1314674] Re: Unable to connect to VCenter 5.5 VimFaultException: Server raised fault: 'Element tag ns0:RetrieveServiceContent uses an undefined namespace prefix ns0
This bug was fixed in the package suds - 0.4.1-11ubuntu0.1
---
suds (0.4.1-11ubuntu0.1) trusty; urgency=medium
* d/p/04-merge-schema.patch: Dropped, because it introduces errors in
namespace detection (LP: #1314674).
-- James PageMon, 09 Jun 2014 18:02:30 +0100
** Changed in: suds (Ubuntu Trusty)
Status: Fix Committed => 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/1314674
Title:
Unable to connect to VCenter 5.5 VimFaultException: Server raised
fault: 'Element tag ns0:RetrieveServiceContent uses an undefined
namespace prefix ns0
Status in OpenStack Compute (Nova):
Invalid
Status in “suds” package in Ubuntu:
Fix Released
Status in “suds” source package in Trusty:
Fix Released
Status in “suds” source package in Utopic:
Fix Released
Bug description:
[Impact]
Users of the Nova VMWare integration can't use the distro provided package.
[Test Case]
sudo apt-get install nova-compute-vmware
(configure /etc/nova/nova.conf to point to a vsphere deployment)
error in original bug report
[Regression potential]
The fix is to drop a distro patch which has all ready been dropped in Debian
and utopic.
[Original Bug Report]
I'm currently trying to integrate an OpenStack testbed (based on Icehouse
nova-2014.1 , Ubuntu 14.04 standard packages) with VCenter. I configured
nova.conf http://docs.openstack.org/trunk/config-reference/content/vmware.html:
compute_driver=vmwareapi.VMwareVCDriver
reserved_host_memory_mb=0
[vmware]
host_ip=192.168.0.146
host_username=root
host_password=
cluster_name=VCOS
datastore_regex=qnap*
Using the password I'm able to login to VCenter using vSphere Web
Client, Cluster VCOS was created using DRS, and I also defined a port
group br-int on the ESXi hosts in the cluster. Although OpenStack Nova
using KVM works like a breeze on two other compute nodes, I constantly
get error messages on the node running VMwareVCDriver in note-
compute.log
2014-04-30 16:44:10.263 1383 ERROR suds.client [-]
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";>
<_this type="ServiceInstance">ServiceInstance
2014-04-30 16:44:10.265 1383 CRITICAL nova.virt.vmwareapi.driver [-] Unable
to connect to server at 192.168.78.103, sleeping for 60 seconds
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver Traceback (most
recent call last):
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver File
"/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/driver.py", line 795, in
_create_session
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver self.vim =
self._get_vim_object()
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver File
"/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/driver.py", line 784, in
_get_vim_object
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver return
vim.Vim(protocol=self._scheme, host=self._host_ip)
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver File
"/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vim.py", line 117, in
__init__
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver
self._service_content = self.retrieve_service_content()
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver File
"/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vim.py", line 120, in
retrieve_service_content
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver return
self.RetrieveServiceContent("ServiceInstance")
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver File
"/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vim.py", line 196, in
vim_request_handler
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver raise
error_util.VimFaultException(fault_list, excep)
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver
VimFaultException: Server raised fault: 'Element tag ns0:RetrieveServiceContent
uses an undefined namespace prefix ns0
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver while parsing
SOAP body
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver at line 1,
column 224
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver while parsing
SOAP envelope
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver at line 1,
column 38
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.driver while parsing
HTTP request before method was determined
2014-04-30 16:44:10.265 1383 TRACE nova.virt.vmwareapi.drive
[Yahoo-eng-team] [Bug 1331170] [NEW] Live migration fails in heterogeneous host OS environment
Public bug reported: The libvirt driver currently does not set the machine type for a KVM guest by default. When not specified, libvirt will use the newest one it knows about. Unfortunately, that can result in live migrations failing if your environment is using different versions of the host OS on compute noes as the destination node may not be able to support the machine type used when the VM was originally started. A simple solution to this is to provide a new option which allows you to specify the default machine type on a per compute node basis (nova.conf option). By using this option, you can ensure that VMs are started with a machine type that will allow it to be live migrated to other nodes in the deployment. ** Affects: nova Importance: Undecided Assignee: Russell Bryant (russellb) Status: New ** Tags: libvirt ** Tags added: libvirt ** Changed in: nova Assignee: (unassigned) => Russell Bryant (russellb) -- 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/1331170 Title: Live migration fails in heterogeneous host OS environment Status in OpenStack Compute (Nova): New Bug description: The libvirt driver currently does not set the machine type for a KVM guest by default. When not specified, libvirt will use the newest one it knows about. Unfortunately, that can result in live migrations failing if your environment is using different versions of the host OS on compute noes as the destination node may not be able to support the machine type used when the VM was originally started. A simple solution to this is to provide a new option which allows you to specify the default machine type on a per compute node basis (nova.conf option). By using this option, you can ensure that VMs are started with a machine type that will allow it to be live migrated to other nodes in the deployment. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1331170/+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 1331176] [NEW] ComputeCapabilitiesFilter fail because cpu_info is loaded as unicode
Public bug reported: cpu_info data is loaded as unicode in HostState. ComputeCapabilitiesFilter fails to get attributes from this property. This will fail: capabilities:cpu_info:features aes capabilities:cpu_info:vendor = Intel while this will pass capabilities:hypervisor_type = QEMU hypervisor_type = QEMU ** Affects: nova Importance: Undecided Assignee: Facundo Maldonado (facundo-n-maldonado) 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/1331176 Title: ComputeCapabilitiesFilter fail because cpu_info is loaded as unicode Status in OpenStack Compute (Nova): In Progress Bug description: cpu_info data is loaded as unicode in HostState. ComputeCapabilitiesFilter fails to get attributes from this property. This will fail: capabilities:cpu_info:features aes capabilities:cpu_info:vendor = Intel while this will pass capabilities:hypervisor_type = QEMU hypervisor_type = QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1331176/+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 1331184] [NEW] floating ip graphic label consistency
Public bug reported: Right now it says: Floating IP (0) -- 10 Available It should be reworded as: "Floating IP ---0 of 10 Used" Related to this bug: https://bugs.launchpad.net/horizon/+bug/1327299 Code to change here: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/templates/access_and_security/floating_ips/_allocate.html#L27 ** 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/1331184 Title: floating ip graphic label consistency Status in OpenStack Dashboard (Horizon): New Bug description: Right now it says: Floating IP (0) -- 10 Available It should be reworded as: "Floating IP ---0 of 10 Used" Related to this bug: https://bugs.launchpad.net/horizon/+bug/1327299 Code to change here: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/templates/access_and_security/floating_ips/_allocate.html#L27 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1331184/+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 1302256] Re: dropdown menus should show default text instead of blank
This bug can now be closed since the other part was fixed too: https://bugs.launchpad.net/horizon/+bug/1325701. :) ** Changed in: horizon 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/1302256 Title: dropdown menus should show default text instead of blank Status in OpenStack Dashboard (Horizon): Fix Released Bug description: 1. Project > Image > Create Image modal Format should not show blank, it should say something like "--- Select Format ---" Please see attached image. 2. Project > Volumes > Create Volume modal If there are no volume types, Types should say "No volume types available" instead of being blank (see 'No key pairs available" in Launch Instance modal > Access & Security tab) To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1302256/+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 1217918] Re: List servers filtered by name wildcard failed for database do not support REGEXP
*** This bug is a duplicate of bug 1230102 ***
https://bugs.launchpad.net/bugs/1230102
Looks like the fix for bug 1230102 should also resolve this:
https://review.openstack.org/#/c/45026/
** Tags added: db2
** This bug has been marked a duplicate of bug 1230102
For oracle database, the usage of REGEXP is not correct for List Servers by
filter.
--
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/1217918
Title:
List servers filtered by name wildcard failed for database do not
support REGEXP
Status in OpenStack Compute (Nova):
Invalid
Bug description:
For non MySQL database(such as DB2 or others), try to list servers using
filter and provide partial server name, it's failed!
---
[root@localhost sqlalchemy]# nova list
+--+-+++-+---+
| ID | Name| Status | Task State |
Power State | Networks |
+--+-+++-+---+
| 17ebc832-7947-40a1-9aeb-423bded822bd | fortest | ACTIVE | None |
Running | network1=10.0.1.4 |
| 7ca3b1f5-7a17-4217-92b0-4175ecfa3c94 | mabc%2 | ACTIVE | None |
Running | network1=10.0.1.3 |
+--+-+++-+---+
[root@localhost sqlalchemy]#
---
Try to list this server with below request.
---
http://10.1.0.40:8774/v2/58e344d219b44eb8b16f40d0b78dace9/servers?name=m
---
Response:
---
{
"servers": []
}
---
But for MySQL database, it's worked.
Request:
---
http://10.1.0.40:8774/v2/58e344d219b44eb8b16f40d0b78dace9/servers?name=m
---
reponse:
---
{
"servers": [
{
"id": "7ca3b1f5-7a17-4217-92b0-4175ecfa3c94",
"links": [
{
"href":
"http://10.1.0.40:8774/v2/58e344d219b44eb8b16f40d0b78dace9/servers/7ca3b1f5-7a17-4217-92b0-4175ecfa3c94";,
"rel": "self"
},
{
"href":
"http://10.1.0.40:8774/58e344d219b44eb8b16f40d0b78dace9/servers/7ca3b1f5-7a17-4217-92b0-4175ecfa3c94";,
"rel": "bookmark"
}
],
"name": "mabc%2"
}
]
}
---
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1217918/+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 1320655] Re: UnicodeDecodeError in the nova gate logs
** Changed in: nova Status: Confirmed => Invalid ** Changed in: nova Assignee: Michael Still (mikalstill) => (unassigned) -- 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/1320655 Title: UnicodeDecodeError in the nova gate logs Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Compute (Nova): Invalid Status in Python client library for Glance: Confirmed Bug description: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOiBcIlVuaWNvZGVEZWNvZGVFcnJvclwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDAwNDI3ODM3NzE0LCJtb2RlIjoiIiwiYW5hbHl6ZV9maWVsZCI6IiJ9 message: "UnicodeDecodeError" Looks like the n-cpu tries to long something not unicide. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1320655/+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 1320655] Re: UnicodeDecodeError in the nova gate logs
Note from chat with mikal: mikal: markwash: commenting out the LOG.debug lines "fixes" the tracebacks, but makes those logging methods useless mikal: i.e. we need to think harder than that ** Also affects: python-glanceclient Importance: Undecided Status: New ** Changed in: python-glanceclient Importance: Undecided => Medium ** Changed in: python-glanceclient Status: New => Confirmed -- 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/1320655 Title: UnicodeDecodeError in the nova gate logs Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Compute (Nova): Invalid Status in Python client library for Glance: Confirmed Bug description: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOiBcIlVuaWNvZGVEZWNvZGVFcnJvclwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDAwNDI3ODM3NzE0LCJtb2RlIjoiIiwiYW5hbHl6ZV9maWVsZCI6IiJ9 message: "UnicodeDecodeError" Looks like the n-cpu tries to long something not unicide. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1320655/+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 1330771] Re: pbr as run time requirement conflicts with distro packaging
There is also a Keystone side to this, in that we import pbr in keystone-all and in keystone/cli.py and it does not belong there. ** Changed in: keystone Status: Invalid => New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1330771 Title: pbr as run time requirement conflicts with distro packaging Status in OpenStack Identity (Keystone): New Status in Python Build Reasonableness: New Bug description: Using PBR for development makes sense, but it should not be a run time requirement for keystone-all or the other tools. All it is doing is reporting the version of the python library, and that does not require any of the rest of PBR. However, PBR pulls in tools that are rightfully build time requirements. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1330771/+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 1331213] [NEW] Compute node configuration issue
Public bug reported: Hello. I'm having a problem using nova node configuration. I have a controller node and a compute node. When I start the service on compute node I get "2014-06-17 18:08:27 15268 DEBUG nova.virt.libvirt.driver [-] Connecting to libvirt: qemu:///system _get_connection /usr/lib/python2.7/dist-packages/n ova/virt/libvirt/driver.py:344 2014-06-17 18:08:28 15268 CRITICAL nova [-] (OperationalError) no such table: instances u'SELECT instances.created_at ..." Environment : Ubuntu 12.x, IceHouse Any help is appreciated. Thank you ** 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/1331213 Title: Compute node configuration issue Status in OpenStack Compute (Nova): New Bug description: Hello. I'm having a problem using nova node configuration. I have a controller node and a compute node. When I start the service on compute node I get "2014-06-17 18:08:27 15268 DEBUG nova.virt.libvirt.driver [-] Connecting to libvirt: qemu:///system _get_connection /usr/lib/python2.7/dist-packages/n ova/virt/libvirt/driver.py:344 2014-06-17 18:08:28 15268 CRITICAL nova [-] (OperationalError) no such table: instances u'SELECT instances.created_at ..." Environment : Ubuntu 12.x, IceHouse Any help is appreciated. Thank you To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1331213/+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 1330771] Re: pbr as run time requirement conflicts with distro packaging
I'll open a separate bug for Keystone ** Changed in: keystone Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1330771 Title: pbr as run time requirement conflicts with distro packaging Status in OpenStack Identity (Keystone): Invalid Status in Python Build Reasonableness: New Bug description: Using PBR for development makes sense, but it should not be a run time requirement for keystone-all or the other tools. All it is doing is reporting the version of the python library, and that does not require any of the rest of PBR. However, PBR pulls in tools that are rightfully build time requirements. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1330771/+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 1331217] [NEW] keystone should not import pbr
Public bug reported: pbr is a build time tool, and pulls in dependencies that are not appropriate for runtime. It is only used for the version string in order to load the config file. Longer issues with pbr are discussed https://bugs.launchpad.net/keystone/+bug/1330771 ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1331217 Title: keystone should not import pbr Status in OpenStack Identity (Keystone): New Bug description: pbr is a build time tool, and pulls in dependencies that are not appropriate for runtime. It is only used for the version string in order to load the config file. Longer issues with pbr are discussed https://bugs.launchpad.net/keystone/+bug/1330771 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1331217/+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 1331092] Re: FlatDHCP manager will hand out networks from other tenants
Removing OSSA task since we don't need an advisory (non-exploitable). ** No longer affects: ossa -- 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/1331092 Title: FlatDHCP manager will hand out networks from other tenants Status in OpenStack Compute (Nova): In Progress Bug description: If FlatDhcpManager is used to create specific networks per tenant, a tenant will get all networks by default instead of just his or her assigned network. Due to context elevation, the network manager doesn't properly ensure that the network is owned by the tenant before it creates a nic. nova network-create --interface eth0 --bridge-interface br100 --project-id --fixed-range 100.0.0.0/24 foonet nova network-create --interface eth1 --bridge-interface br200 --project-id --fixed-range 100.0.0.0/24 barnet A instance create inside the foo tenant will get an interface on both foonet and barnet. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1331092/+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 1331240] [NEW] Big Switch Unit test failures with testtools
Public bug reported: The big switch unit tests fail when being run in debug mode with the ./run_tests.sh script [1]. 1. ./run_tests.sh neutron.tests.unit.bigswitch.test_security_groups.TestSecServerRpcCallBack.test_security_group_ra_rules_for_devices_ipv6_gateway_global produces http://paste.openstack.org/show/84344/ ** 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/1331240 Title: Big Switch Unit test failures with testtools Status in OpenStack Neutron (virtual network service): New Bug description: The big switch unit tests fail when being run in debug mode with the ./run_tests.sh script [1]. 1. ./run_tests.sh neutron.tests.unit.bigswitch.test_security_groups.TestSecServerRpcCallBack.test_security_group_ra_rules_for_devices_ipv6_gateway_global produces http://paste.openstack.org/show/84344/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1331240/+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 1331249] [NEW] Big Switch: Uneccesary init method and server_timeout param
Public bug reported: Both the Big Switch Plugin and ML2 driver allow a server_timeout param in the initialization methods that can never be set by a user so it doesn't serve a purpose [1][2]. With those removed, the entire __init__ method of the base class can be removed as well. 1. https://github.com/openstack/neutron/blob/d379170109982a53544d01566ba9231d66b24ed4/neutron/plugins/bigswitch/plugin.py#L171 2. https://github.com/openstack/neutron/blob/1a116d24a955c9e45fa8a29998d09da0350be4ab/neutron/plugins/ml2/drivers/mech_bigswitch/driver.py#L46 ** 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/1331249 Title: Big Switch: Uneccesary init method and server_timeout param Status in OpenStack Neutron (virtual network service): New Bug description: Both the Big Switch Plugin and ML2 driver allow a server_timeout param in the initialization methods that can never be set by a user so it doesn't serve a purpose [1][2]. With those removed, the entire __init__ method of the base class can be removed as well. 1. https://github.com/openstack/neutron/blob/d379170109982a53544d01566ba9231d66b24ed4/neutron/plugins/bigswitch/plugin.py#L171 2. https://github.com/openstack/neutron/blob/1a116d24a955c9e45fa8a29998d09da0350be4ab/neutron/plugins/ml2/drivers/mech_bigswitch/driver.py#L46 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1331249/+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 1331258] [NEW] workflow default success/error messaging bug
Public bug reported:
Default workflow success and failure messages are:
success_message = _("%s completed successfully.")
failure_message = _("%s did not complete.")
https://github.com/openstack/horizon/blob/master/horizon/workflows/base.py#L595
According to the class definition, failure message is supposed to be:
"{{ workflow.name }} did not complete."
However, it ends up using the row.name and appearing as "demo did not
complete."
When it should be "Edit project did not complete".
Please see attachment.
You can try this out for yourself by going to /admin/projects/workflows.py
(https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/projects/workflows.py#L346)
and commenting out the two success and failure messages.
** Affects: horizon
Importance: Undecided
Status: New
** Attachment added: "Untitled.png"
https://bugs.launchpad.net/bugs/1331258/+attachment/4133790/+files/Untitled.png
--
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/1331258
Title:
workflow default success/error messaging bug
Status in OpenStack Dashboard (Horizon):
New
Bug description:
Default workflow success and failure messages are:
success_message = _("%s completed successfully.")
failure_message = _("%s did not complete.")
https://github.com/openstack/horizon/blob/master/horizon/workflows/base.py#L595
According to the class definition, failure message is supposed to be:
"{{ workflow.name }} did not complete."
However, it ends up using the row.name and appearing as "demo did not
complete."
When it should be "Edit project did not complete".
Please see attachment.
You can try this out for yourself by going to /admin/projects/workflows.py
(https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/projects/workflows.py#L346)
and commenting out the two success and failure messages.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1331258/+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 1331271] [NEW] NoReverseMatch: u"'horizon" is not a registered namespace
Public bug reported:
CentOS 6.5 with Icehouse OpenStack controller running latest stable yum
version of horizon. when I click on the pseudo-folder of container, Following
error will display:
NoReverseMatch: u"'horizon" is not a registered namespace
simular problem with
https://bugs.launchpad.net/horizon/+bug/131
https://bugs.launchpad.net/horizon/+bug/1296273
but impact source file is :
/usr/share/openstack-dashboard/openstack_dashboard/dashboards/project/containers/templates/containers/index.html
Update index.html lline 16&21 as following, then the pseudo-folder could be
displayed correctly:
line 16, change it from
{{
container_name }} : /
to
{{
container_name }} : /
line 21,change it from
{{ folder.0 }} /
to
{{ folder.0 }} /
BTW: The pseudo-folder couldn't be delete which is related to another exists
bug:"
https://bugs.launchpad.net/horizon/+bug/1317016
** 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/1331271
Title:
NoReverseMatch: u"'horizon" is not a registered namespace
Status in OpenStack Dashboard (Horizon):
New
Bug description:
CentOS 6.5 with Icehouse OpenStack controller running latest stable yum
version of horizon. when I click on the pseudo-folder of container, Following
error will display:
NoReverseMatch: u"'horizon" is not a registered namespace
simular problem with
https://bugs.launchpad.net/horizon/+bug/131
https://bugs.launchpad.net/horizon/+bug/1296273
but impact source file is :
/usr/share/openstack-dashboard/openstack_dashboard/dashboards/project/containers/templates/containers/index.html
Update index.html lline 16&21 as following, then the pseudo-folder could be
displayed correctly:
line 16, change it from
{{ container_name }} : /
to
{{
container_name }} : /
line 21,change it from
{{ folder.0 }} /
to
{{ folder.0 }} /
BTW: The pseudo-folder couldn't be delete which is related to another exists
bug:"
https://bugs.launchpad.net/horizon/+bug/1317016
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1331271/+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 1267723] Re: nova interface-attach doesn't work if port|network|fixed id is omitted
This is a problem:
# nova --insecure interface-attach cirros
ERROR: Failed to attach interface (HTTP 500) (Request-ID:
req-0d424f10-0974-41cc-b1a6-9c945f96997c)
https://github.com/openstack/nova/blob/master/nova/compute/manager.py file has
the check:
if len(network_info) != 1:
LOG.error(_('allocate_port_for_instance returned %(ports)s ports')
% dict(ports=len(network_info)))
However, in
https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py:
_get_available_networks()
if no network specified, it will get all networks in the tenant.
If more than one network in the tenant, this will definitely causing the
above check failed.
** This bug is no longer a duplicate of bug 1245683
interface-attach: raises 500 error if invalid network
--
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/1267723
Title:
nova interface-attach doesn't work if port|network|fixed id is omitted
Status in OpenStack Compute (Nova):
New
Bug description:
when use 'interface-attach' to attach interface to a vm with
port|network|fixed id is omitted, it will be success if there is one
network in that tenant, but it will be failed if there are more than
one network in that tenant, also, when nterface-attach faield, there
will be residual port in neutron which will not automatically deleted
, nova latest code has the same problem!
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1267723/+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 1331307] [NEW] "nova show instance_id" gives duplicate security group info (neutron enabled, nova-network disabled)
Public bug reported: How to reproduce the bug: 1. devstack with neutron enabled (nova-network disabled) Num Name Flags 0 shell $ 1 key $ 2 horizon $ 3 s-proxy $ 4 s-object $ 5 s-container $ 6 s-account $ 7 g-reg $ 8 g-api $ 9 n-api $ 10 q-svc $ 11 q-agt $ 12 q-dhcp $ 13 q-l3 $ 14 q-meta $ 15 n-cpu $ 16 n-cond $ 17 n-crt $ 18 n-sch $ 19 n-cauth $ 20 n-obj $ 21 c-api $ 22 c-sch
[Yahoo-eng-team] [Bug 1331317] [NEW] test_create_instance_with_neutronv2_fixed_ip_already_in_use does not test the purposes.
Public bug reported: In test_create_instance_with_neutronv2_fixed_ip_already_in_use of both v2 and v3, these tests pass wrong parameters "fixed-ip" instead of valid parameter "fixed_ip". The purposes of these tests are to check the behaviors when passing in-use addresses, but current tests contain two negative factors and we cannot test the purposes now. ** Affects: nova Importance: Undecided Assignee: Ken'ichi Ohmichi (oomichi) Status: In Progress ** Changed in: nova Assignee: (unassigned) => Ken'ichi Ohmichi (oomichi) ** Changed in: nova Status: New => 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/1331317 Title: test_create_instance_with_neutronv2_fixed_ip_already_in_use does not test the purposes. Status in OpenStack Compute (Nova): In Progress Bug description: In test_create_instance_with_neutronv2_fixed_ip_already_in_use of both v2 and v3, these tests pass wrong parameters "fixed-ip" instead of valid parameter "fixed_ip". The purposes of these tests are to check the behaviors when passing in-use addresses, but current tests contain two negative factors and we cannot test the purposes now. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1331317/+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 1331321] [NEW] VMware: iSCSI static target needs to be removed from all hosts
Public bug reported: iSCSI static targets need to be removed from all hosts of the cluster asynchronously on detach volume. ** 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/1331321 Title: VMware: iSCSI static target needs to be removed from all hosts Status in OpenStack Compute (Nova): New Bug description: iSCSI static targets need to be removed from all hosts of the cluster asynchronously on detach volume. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1331321/+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 1331329] [NEW] success_url is unneeded in PasswordView
Public bug reported: Since PasswordForm handle success return http.HttpResponseRedirect(settings.LOGOUT_URL), it's no need to set success_url in PasswordView. see: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/settings/password/forms.py#L60 ** Affects: horizon Importance: Undecided Assignee: Zhenguo Niu (niu-zglinux) Status: New ** Changed in: horizon Assignee: (unassigned) => Zhenguo Niu (niu-zglinux) -- 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/1331329 Title: success_url is unneeded in PasswordView Status in OpenStack Dashboard (Horizon): New Bug description: Since PasswordForm handle success return http.HttpResponseRedirect(settings.LOGOUT_URL), it's no need to set success_url in PasswordView. see: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/settings/password/forms.py#L60 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1331329/+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
