[Yahoo-eng-team] [Bug 1411312] Re: tempest.api.compute.servers.test_create_server.ServersTestManualDisk.test_verify_multiple_nics_order intermittent fails in the gate
change https://review.openstack.org/#/c/147775/ submitted. ** Changed in: nova Status: Confirmed = In Progress ** Project changed: nova = tempest -- 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/1411312 Title: tempest.api.compute.servers.test_create_server.ServersTestManualDisk.test_verify_multiple_nics_order intermittent fails in the gate Status in Tempest: In Progress Bug description: http://logs.openstack.org/36/147336/1/gate/gate-tempest-dsvm-neutron- full/a695425/console.html#_2015-01-15_01_13_40_304 2015-01-15 01:40:06.862 | Traceback (most recent call last): 2015-01-15 01:40:06.862 | File tempest/api/compute/servers/test_create_server.py, line 181, in test_verify_multiple_nics_order 2015-01-15 01:40:06.863 | self.assertEqual(expected_addr, addr) 2015-01-15 01:40:06.863 | File /usr/local/lib/python2.7/dist-packages/testtools/testcase.py, line 348, in assertEqual 2015-01-15 01:40:06.863 | self.assertThat(observed, matcher, message) 2015-01-15 01:40:06.863 | File /usr/local/lib/python2.7/dist-packages/testtools/testcase.py, line 433, in assertThat 2015-01-15 01:40:06.863 | raise mismatch_error 2015-01-15 01:40:06.863 | MismatchError: ['19.80.0.2', '19.86.0.2'] != [u'19.80.0.3', u'19.86.0.3'] http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwidGVtcGVzdC5hcGkuY29tcHV0ZS5zZXJ2ZXJzLnRlc3RfY3JlYXRlX3NlcnZlci5TZXJ2ZXJzVGVzdE1hbnVhbERpc2sudGVzdF92ZXJpZnlfbXVsdGlwbGVfbmljc19vcmRlclwiIEFORCBtZXNzYWdlOlwiRkFJTEVEXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6ImN1c3RvbSIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJmcm9tIjoiMjAxNS0wMS0wMVQxNjozNjowOSswMDowMCIsInRvIjoiMjAxNS0wMS0xNVQxNjozNjowOSswMDowMCIsInVzZXJfaW50ZXJ2YWwiOiIwIn0sInN0YW1wIjoxNDIxMzM5ODE0ODE5fQ== 14 hits in the last 10 days, going back to 1/8 for the first one. check, gate and experimental queues, all failures, looks like neutronv2 API only. To manage notifications about this bug go to: https://bugs.launchpad.net/tempest/+bug/1411312/+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 1411566] [NEW] Type and Code fields' not marked manadatory in Access-Security tab
Public bug reported: The 'Type' and 'Code' are the required fields for managing rules in Access and Security tab, but they do not have the asterisk marked against them. To replicate this, please follow - Projects - Access and Security - Add/Edit Rules (on any security group that has been created) - 'Custom ICMP Rule' ** Affects: horizon Importance: Undecided Assignee: Swati Shukla (swati-shukla1) Status: New ** Changed in: horizon Assignee: (unassigned) = Swati Shukla (swati-shukla1) -- 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/1411566 Title: Type and Code fields' not marked manadatory in Access-Security tab Status in OpenStack Dashboard (Horizon): New Bug description: The 'Type' and 'Code' are the required fields for managing rules in Access and Security tab, but they do not have the asterisk marked against them. To replicate this, please follow - Projects - Access and Security - Add/Edit Rules (on any security group that has been created) - 'Custom ICMP Rule' To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1411566/+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 1411595] [NEW] Overview displays mixture of metrics in abbreviated and non-abbreviated format
Public bug reported: The Instance Overview page on Horizon displays some metrics' units in non-abbreviated, and some in abbreviated format. For example, RAM Used 0Bytes of 50GB, Volume storage Used 0Bytes of 1000GB (see screenshot). This is inconsistent. A better description would read 0B of 1000GB ** Affects: horizon Importance: Undecided Assignee: Pedro Kostelec (pedro-kostelec) Status: New ** Tags: low-hanging-fruit ux ** Attachment added: Instance Overview OpenStack Dashboard.png https://bugs.launchpad.net/bugs/1411595/+attachment/4299904/+files/Instance%20Overview%20%20%20OpenStack%20Dashboard.png ** Changed in: horizon Assignee: (unassigned) = Pedro Kostelec (pedro-kostelec) -- 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/1411595 Title: Overview displays mixture of metrics in abbreviated and non- abbreviated format Status in OpenStack Dashboard (Horizon): New Bug description: The Instance Overview page on Horizon displays some metrics' units in non-abbreviated, and some in abbreviated format. For example, RAM Used 0Bytes of 50GB, Volume storage Used 0Bytes of 1000GB (see screenshot). This is inconsistent. A better description would read 0B of 1000GB To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1411595/+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 1411625] [NEW] Keystone not throwing any exception when there is no proper OS credentails.
Public bug reported: When we miss any of the environment variable, Keystone commands do not throw any error, it just simply output nothing. But when when we run nova command it outputs proper error message. So similarly even keystone should throw appropriate error message when any of the environment variable is missing. Steps to reproduce. root@ubuntu:~# unset OS_TENANT_NAME root@ubuntu:~# keystone user-list root@ubuntu:~# nova list ERROR (CommandError): You must provide a tenant name or tenant id via --os-tenant-name, --os-tenant-id, env[OS_TENANT_NAME] or env[OS_TENANT_ID] root@ubuntu:~# ** 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/1411625 Title: Keystone not throwing any exception when there is no proper OS credentails. Status in OpenStack Identity (Keystone): New Bug description: When we miss any of the environment variable, Keystone commands do not throw any error, it just simply output nothing. But when when we run nova command it outputs proper error message. So similarly even keystone should throw appropriate error message when any of the environment variable is missing. Steps to reproduce. root@ubuntu:~# unset OS_TENANT_NAME root@ubuntu:~# keystone user-list root@ubuntu:~# nova list ERROR (CommandError): You must provide a tenant name or tenant id via --os-tenant-name, --os-tenant-id, env[OS_TENANT_NAME] or env[OS_TENANT_ID] root@ubuntu:~# To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1411625/+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 1411688] [NEW] qos is broken
Public bug reported: testing the bug submission process ** Affects: neutron Importance: Undecided Assignee: Victor Howard (victor-r-howard) Status: New ** Changed in: neutron Assignee: (unassigned) = Victor Howard (victor-r-howard) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1411688 Title: qos is broken Status in OpenStack Neutron (virtual network service): New Bug description: testing the bug submission process To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1411688/+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 1411708] [NEW] AbsoluteLimitsNegativeTestJSON.test_max_image_meta_exceed_limit fails to fail
Public bug reported: This is a negative test that is supposed to fail with an over-quota exception when creating the server but it looks like it's successfully creating the server request at times: http://logs.openstack.org/00/135700/45/check/check-tempest-dsvm- postgres-full/3bb3614/console.html#_2015-01-16_00_57_07_456 So there is some race here. http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwidGVtcGVzdC5hcGkuY29tcHV0ZS5saW1pdHMudGVzdF9hYnNvbHV0ZV9saW1pdHNfbmVnYXRpdmUuQWJzb2x1dGVMaW1pdHNOZWdhdGl2ZVRlc3RKU09OLnRlc3RfbWF4X2ltYWdlX21ldGFfZXhjZWVkX2xpbWl0XCIgQU5EIG1lc3NhZ2U6XCJGQUlMRURcIiBBTkQgdGFnczpcImNvbnNvbGVcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyMTQyMTQyNTU2N30= 31 hits in 7 days, all check queue according to that but it's on multiple changes. ** 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/1411708 Title: AbsoluteLimitsNegativeTestJSON.test_max_image_meta_exceed_limit fails to fail Status in OpenStack Compute (Nova): New Bug description: This is a negative test that is supposed to fail with an over-quota exception when creating the server but it looks like it's successfully creating the server request at times: http://logs.openstack.org/00/135700/45/check/check-tempest-dsvm- postgres-full/3bb3614/console.html#_2015-01-16_00_57_07_456 So there is some race here. http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwidGVtcGVzdC5hcGkuY29tcHV0ZS5saW1pdHMudGVzdF9hYnNvbHV0ZV9saW1pdHNfbmVnYXRpdmUuQWJzb2x1dGVMaW1pdHNOZWdhdGl2ZVRlc3RKU09OLnRlc3RfbWF4X2ltYWdlX21ldGFfZXhjZWVkX2xpbWl0XCIgQU5EIG1lc3NhZ2U6XCJGQUlMRURcIiBBTkQgdGFnczpcImNvbnNvbGVcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyMTQyMTQyNTU2N30= 31 hits in 7 days, all check queue according to that but it's on multiple changes. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1411708/+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 1411708] Re: AbsoluteLimitsNegativeTestJSON.test_max_image_meta_exceed_limit fails to fail
This actually looks like a tempest bug, there is code in the nova.compute.api where it's validating the 'metadata_items' lenght against quota_metadata_items and that's probably racing against another test in tempest that sets the global default quotas to -1 (unlimited), so the negative test fails since the quota is -1 and the server is created even though it's metadata_items are lenth 129 (128 is the default). ** Changed in: nova Status: New = Invalid ** Also affects: tempest Importance: Undecided Status: New ** Changed in: tempest Status: New = Triaged ** Changed in: tempest Assignee: (unassigned) = Matt Riedemann (mriedem) ** Changed in: tempest Importance: Undecided = Medium -- 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/1411708 Title: AbsoluteLimitsNegativeTestJSON.test_max_image_meta_exceed_limit fails to fail Status in OpenStack Compute (Nova): Invalid Status in Tempest: Triaged Bug description: This is a negative test that is supposed to fail with an over-quota exception when creating the server but it looks like it's successfully creating the server request at times: http://logs.openstack.org/00/135700/45/check/check-tempest-dsvm- postgres-full/3bb3614/console.html#_2015-01-16_00_57_07_456 So there is some race here. http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwidGVtcGVzdC5hcGkuY29tcHV0ZS5saW1pdHMudGVzdF9hYnNvbHV0ZV9saW1pdHNfbmVnYXRpdmUuQWJzb2x1dGVMaW1pdHNOZWdhdGl2ZVRlc3RKU09OLnRlc3RfbWF4X2ltYWdlX21ldGFfZXhjZWVkX2xpbWl0XCIgQU5EIG1lc3NhZ2U6XCJGQUlMRURcIiBBTkQgdGFnczpcImNvbnNvbGVcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyMTQyMTQyNTU2N30= 31 hits in 7 days, all check queue according to that but it's on multiple changes. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1411708/+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 1411719] [NEW] The full log of gate-horizon-docs job contains a lot of errors, yet it succeeds
Public bug reported: If you look at e.g. https://jenkins05.openstack.org/job/gate-horizon- docs/2699/consoleFull you'll find there are a lot of WARNING/SEVERE/ERROR messages due to sphinx failing to recognize some attributes/methods/whatever it is. Yet the gate-job succeeds in Jenkins. Putting aside the actual problems the Sphinx encounters, the problem that should be solved first is making gate-horizon-docs job more honest. In case you are not able to open the specified link, you could open the full log of any other horizon commit by clicking the gate-horizon-docs link inside any of horizon commits at http://status.openstack.org/zuul/ ** Affects: horizon Importance: Undecided Status: New ** Summary changed: - The full log of get-horizon-docs job contains a lot of errors, yet it succeeds + The full log of gate-horizon-docs job contains a lot of errors, yet it succeeds -- 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/1411719 Title: The full log of gate-horizon-docs job contains a lot of errors, yet it succeeds Status in OpenStack Dashboard (Horizon): New Bug description: If you look at e.g. https://jenkins05.openstack.org/job/gate-horizon- docs/2699/consoleFull you'll find there are a lot of WARNING/SEVERE/ERROR messages due to sphinx failing to recognize some attributes/methods/whatever it is. Yet the gate-job succeeds in Jenkins. Putting aside the actual problems the Sphinx encounters, the problem that should be solved first is making gate-horizon-docs job more honest. In case you are not able to open the specified link, you could open the full log of any other horizon commit by clicking the gate-horizon- docs link inside any of horizon commits at http://status.openstack.org/zuul/ To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1411719/+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 1411752] [NEW] linuxbridge : HA routers interact badly with l2pop
Public bug reported:
This bug comes from a split of the bug #1365476 which will now be
dedicated to an OVS fix
There is big difference between OVS and LB when using vxlan tunnels
managed by l2pop :
-In OVS, vxlan tunnels are plugged into the br-tun bridge. L2pop
messages will manage the tunnel creation, and, if configured in the
agent, will add an ARP responding entry. If no ARP entry is matched, ARP
packets will be flooded to every vxlan tunnel, and the correct tunnel
will be learned.
-In LB, when l2pop is activated, vxlan tunnel ports are created with the
mode proxy to activate the ARP responder, populated by l2pop. If a ARP
packet doesn't match any entry in the ARP responder table of any of the
vxlan tunnel ports, ARP packets are dropped. There is no fallback mode
which would flood the packet to every vxlan tunnels to learn the correct
tunnel for the following packets, and populate the ARP table.
A possible implementation to fix this issue would be to add a multi-bound flag
to fdb entries that correspond to a port which is hosted on several hosts (such
as HA routers' ports).
The corresponding fdb message would looks like this :
{net_id:
{port:
{agent_ip1 :
{mac1, ip1, multi-bound}
}
{agent_ip2 :
{mac1, ip1, multi-bound}
}
}
network_type:
vxlan,
segment_id:
id
}
When the LB agent will receive this fdb message, it will populate the
corresponding ARP responder entry (through the ip neigh replace command), but
won't populate the fdb entry (through the bridge fdb add command).
This will result in having packets to HA router ports flooded to every vxlan
tunnels. Once the first response will be received, the vxlan kernel module will
learn on which vxlan tunnel the following packets have to be sent.
** Affects: neutron
Importance: Undecided
Status: New
** Tags: l2-pop linuxbridge
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1411752
Title:
linuxbridge : HA routers interact badly with l2pop
Status in OpenStack Neutron (virtual network service):
New
Bug description:
This bug comes from a split of the bug #1365476 which will now be
dedicated to an OVS fix
There is big difference between OVS and LB when using vxlan tunnels
managed by l2pop :
-In OVS, vxlan tunnels are plugged into the br-tun bridge. L2pop
messages will manage the tunnel creation, and, if configured in the
agent, will add an ARP responding entry. If no ARP entry is matched,
ARP packets will be flooded to every vxlan tunnel, and the correct
tunnel will be learned.
-In LB, when l2pop is activated, vxlan tunnel ports are created with
the mode proxy to activate the ARP responder, populated by l2pop. If
a ARP packet doesn't match any entry in the ARP responder table of any
of the vxlan tunnel ports, ARP packets are dropped. There is no
fallback mode which would flood the packet to every vxlan tunnels to
learn the correct tunnel for the following packets, and populate the
ARP table.
A possible implementation to fix this issue would be to add a multi-bound
flag to fdb entries that correspond to a port which is hosted on several hosts
(such as HA routers' ports).
The corresponding fdb message would looks like this :
{net_id:
{port:
{agent_ip1 :
{mac1, ip1, multi-bound}
}
{agent_ip2 :
{mac1, ip1, multi-bound}
}
}
network_type:
vxlan,
segment_id:
id
}
When the LB agent will receive this fdb message, it will populate the
corresponding ARP responder entry (through the ip neigh replace command), but
won't populate the fdb entry (through the bridge fdb add command).
This will result in having packets to HA router ports flooded to every vxlan
tunnels. Once the first response will be received, the vxlan kernel module will
learn on which vxlan tunnel the following packets have to be sent.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1411752/+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 1411482] Re: save() takes exactly 1 argument (2 given)
This error is coming from the nova compute log here. http://logs.openstack.org/10/115110/20/check/check-tempest-dsvm-neutron- pg-full-2/3c885b8/logs/screen-n-cpu.txt.gz 2015-01-16 01:53:19.798 ERROR oslo.messaging.rpc.dispatcher [req-6bd7d570-7e04-4118-9547-6f8b6fdd67fa TestMinimumBasicScenario-1445783167 TestMinimumBasicScenario-1666592455] Exception during message handling: save() takes exactly 1 argument (2 given) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher Traceback (most recent call last): 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 137, in _dispatch_and_reply 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher incoming.message)) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 180, in _dispatch 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher return self._do_dispatch(endpoint, method, ctxt, args) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 126, in _do_dispatch 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher result = getattr(endpoint, method)(ctxt, **new_args) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/exception.py, line 88, in wrapped 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher payload) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py, line 82, in __exit__ 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/exception.py, line 71, in wrapped 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher return f(self, context, *args, **kw) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 296, in decorated_function 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher pass 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py, line 82, in __exit__ 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 281, in decorated_function 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 346, in decorated_function 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 324, in decorated_function 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher kwargs['instance'], e, sys.exc_info()) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py, line 82, in __exit__ 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 312, in decorated_function 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 2999, in reboot_instance 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher self._set_instance_obj_error_state(context, instance) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py, line 82, in __exit__ 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 2980, in reboot_instance 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher bad_volumes_callback=bad_volumes_callback) 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/virt/libvirt/driver.py, line 2028, in reboot 2015-01-16 01:53:19.798 30555 TRACE oslo.messaging.rpc.dispatcher
[Yahoo-eng-team] [Bug 1411807] [NEW] linuxbridge using mulicast vxlan w/o l2pop fails
Public bug reported: I am running Ubuntu 14.04 with a source Juno install updated as of yesterday. I have two network nodes and two compute nodes. When a VM is booted the broadcast DHCP request goes out and is received by the network node dnsmasq process. The unicast DHCP response is sent and is received by the compute node. It can be captured on the vxlan and Linux bridge interfaces but is never forwarded to the VM's tap interface which is on the bridge.. tcpdump on VM's tap interface. DHCP requests go out but the reply is never forwarded to the VM: root@compute:~# tcpdump -e -n -vv -i tapde7ffb39-b7 tcpdump: WARNING: tapde7ffb39-b7: no IPv4 address assigned tcpdump: listening on tapde7ffb39-b7, link-type EN10MB (Ethernet), capture size 65535 bytes 16:18:54.614728 fa:16:3e:32:93:95 ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 315) 0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from fa:16:3e:32:93:95, length 287, xid 0x8c595e0b, Flags [none] (0x) Client-Ethernet-Address fa:16:3e:32:93:95 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether fa:16:3e:32:93:95 MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 9: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, MTU, BR, NTP Classless-Static-Route Vendor-Class Option 60, length 12: udhcp 1.20.1 Hostname Option 12, length 3: one 16:18:54.615002 fa:16:3e:32:93:95 ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 315) 0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from fa:16:3e:32:93:95, length 287, xid 0x8c595e0b, Flags [none] (0x) Client-Ethernet-Address fa:16:3e:32:93:95 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether fa:16:3e:32:93:95 MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 9: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, MTU, BR, NTP Classless-Static-Route Vendor-Class Option 60, length 12: udhcp 1.20.1 Hostname Option 12, length 3: one 16:18:55.066473 fa:16:3e:32:93:95 33:33:ff:32:93:95, ethertype IPv6 (0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length: 24) :: ff02::1:ff32:9395: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who has fe80::f816:3eff:fe32:9395 tcpdump on the that has both the VM's tap interface and the ethernet vxlan sub-interface. DHCP request goes out and the DHCP reply comes back but is not forwarded to the tap interface: root@compute:~# tcpdump -e -n -vv -i brq475b2aeb-b5 tcpdump: WARNING: brq475b2aeb-b5: no IPv4 address assigned 16:18:54.614728 fa:16:3e:32:93:95 ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 315) 0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from fa:16:3e:32:93:95, length 287, xid 0x8c595e0b, Flags [none] (0x) Client-Ethernet-Address fa:16:3e:32:93:95 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether fa:16:3e:32:93:95 MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 9: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, MTU, BR, NTP Classless-Static-Route Vendor-Class Option 60, length 12: udhcp 1.20.1 Hostname Option 12, length 3: one 16:18:54.614983 fa:16:3e:32:93:95 ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 315) 0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from fa:16:3e:32:93:95, length 287, xid 0x8c595e0b, Flags [none] (0x) Client-Ethernet-Address fa:16:3e:32:93:95 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether fa:16:3e:32:93:95 MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 9: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, MTU, BR, NTP Classless-Static-Route Vendor-Class Option 60, length 12: udhcp 1.20.1 Hostname Option 12, length 3: one 16:18:54.615946 fa:16:3e:e3:35:28
[Yahoo-eng-team] [Bug 1411806] [NEW] project/containers/forms.py imports containers/tables only for the wrap_delimiter function
Public bug reported: openstack_dashboard/dashboards/project/containers/forms.py imports containers/tables.py just for the 'wrap_delimiter' function. This function should be moved to a new containers/utils.py, and then imported to both forms and tables. ** Affects: horizon Importance: Undecided Assignee: Rob Cresswell (robcresswell) Status: New ** Tags: low-hanging-fruit ** Changed in: horizon Assignee: (unassigned) = Rob Cresswell (robcresswell) ** Tags added: low-hanging-fruit -- 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/1411806 Title: project/containers/forms.py imports containers/tables only for the wrap_delimiter function Status in OpenStack Dashboard (Horizon): New Bug description: openstack_dashboard/dashboards/project/containers/forms.py imports containers/tables.py just for the 'wrap_delimiter' function. This function should be moved to a new containers/utils.py, and then imported to both forms and tables. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1411806/+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 1411813] [NEW] glance-cache-manage image_cache_max_size doc is ambiguous
Public bug reported: The description in the documentation is ambiguous. There is not the certainty that the image_max_size parameter is about the sum of all the images or just one image. http://docs.openstack.org/developer/glance/cache.html In the file: /etc/glance/glance-cache.conf, it just says: # Max cache size in bytes which implies the whole size of the cache (sum of all image sizes). But the doc somewhat implies image (?). ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1411813 Title: glance-cache-manage image_cache_max_size doc is ambiguous Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: The description in the documentation is ambiguous. There is not the certainty that the image_max_size parameter is about the sum of all the images or just one image. http://docs.openstack.org/developer/glance/cache.html In the file: /etc/glance/glance-cache.conf, it just says: # Max cache size in bytes which implies the whole size of the cache (sum of all image sizes). But the doc somewhat implies image (?). To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1411813/+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 1411482] Re: save() takes exactly 1 argument (2 given)
Thanks David! You beat me to it. ** No longer affects: tempest ** Changed in: nova 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/1411482 Title: save() takes exactly 1 argument (2 given) Status in OpenStack Compute (Nova): Confirmed Bug description: Logstash: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwic2F2ZSgpIHRha2VzIGV4YWN0bHkgMSBhcmd1bWVudCAoMiBnaXZlbiknXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjE3MjgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MjEzNzQyMjEyNzR9 One instance: http://logs.openstack.org/10/115110/20/check/check-tempest-dsvm- neutron-pg-full-2/3c885b8/logs/testr_results.html.gz Have not root caused it yet, and it affects a few projects To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1411482/+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 1411816] [NEW] DB failure during functional job run
Public bug reported: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiT3BlcmF0aW9uYWxFcnJvcjogKE9wZXJhdGlvbmFsRXJyb3IpIHVucmVjb2duaXplZCB0b2tlbjogXCJAXCIgJ1NFTEVDVCBAQHR4X2lzb2xhdGlvbjsnICgpXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjE3MjgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MjE0MzgwOTU4NzJ9 ** 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/1411816 Title: DB failure during functional job run Status in OpenStack Neutron (virtual network service): New Bug description: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiT3BlcmF0aW9uYWxFcnJvcjogKE9wZXJhdGlvbmFsRXJyb3IpIHVucmVjb2duaXplZCB0b2tlbjogXCJAXCIgJ1NFTEVDVCBAQHR4X2lzb2xhdGlvbjsnICgpXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjE3MjgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MjE0MzgwOTU4NzJ9 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1411816/+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 1411829] [NEW] CentOS 7 should be treated like RHEL 7 in dist/rhel.py
Public bug reported:
cloudinit/dists/rhel.py contains the follow code to determine if systemd
is in use:
def uses_systemd(self):
# Fedora 18 and RHEL 7 were the first adopters in their series
(dist, vers) = util.system_info()['dist'][:2]
major = (int)(vers.split('.')[0])
return ((dist.startswith('Red Hat Enterprise Linux') and major = 7)
or (dist.startswith('Fedora') and major = 18))
This will not produce the correct behavior on CentOS 7, Scientific LInux 7, or
any other RHEL-based distribution. Among other issues, this will prevent
cloud-init from setting the system hostname correctly. Because these
distributions are treated like RHEL6 and earlier, cloud-init writes the
persistent hostname into /etc/sysconfig/network, but the hostname is not read
from this file when the system boots.
I propose that we replace uses_systemd with the following:
def uses_systemd(self):
return os.path.isfile('/usr/bin/systemctl')
** Affects: cloud-init
Importance: Undecided
Status: New
--
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/1411829
Title:
CentOS 7 should be treated like RHEL 7 in dist/rhel.py
Status in Init scripts for use on cloud images:
New
Bug description:
cloudinit/dists/rhel.py contains the follow code to determine if
systemd is in use:
def uses_systemd(self):
# Fedora 18 and RHEL 7 were the first adopters in their series
(dist, vers) = util.system_info()['dist'][:2]
major = (int)(vers.split('.')[0])
return ((dist.startswith('Red Hat Enterprise Linux') and major = 7)
or (dist.startswith('Fedora') and major = 18))
This will not produce the correct behavior on CentOS 7, Scientific LInux 7,
or any other RHEL-based distribution. Among other issues, this will prevent
cloud-init from setting the system hostname correctly. Because these
distributions are treated like RHEL6 and earlier, cloud-init writes the
persistent hostname into /etc/sysconfig/network, but the hostname is not read
from this file when the system boots.
I propose that we replace uses_systemd with the following:
def uses_systemd(self):
return os.path.isfile('/usr/bin/systemctl')
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1411829/+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 1411836] [NEW] Configuration files should not be manually updated
Public bug reported: The configuration files (glance-api.conf, glance-cache.conf, glance- registry.conf etc) are currently manually synced with the options defined in the code. This is causing an unnecessary amount of contributor's effort to maintain, especially when we can automatically keep them up to date using oslo-config-generator. They have also not been correctly updated in the past; glance-cache.conf does not have any of the deprecated glance store options marked as such, for example. A slight complication is some options currently have better documentation in the example config files, rather than the help text defined in the oslo.config option (example on current master: [DEFAULT]/property_protection_file). These options should be updated with the better documentation before automatic syncing takes place. ** Affects: glance Importance: Undecided Assignee: Louis Taylor (kragniz) Status: New ** Changed in: glance Assignee: (unassigned) = Louis Taylor (kragniz) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1411836 Title: Configuration files should not be manually updated Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: The configuration files (glance-api.conf, glance-cache.conf, glance- registry.conf etc) are currently manually synced with the options defined in the code. This is causing an unnecessary amount of contributor's effort to maintain, especially when we can automatically keep them up to date using oslo-config-generator. They have also not been correctly updated in the past; glance-cache.conf does not have any of the deprecated glance store options marked as such, for example. A slight complication is some options currently have better documentation in the example config files, rather than the help text defined in the oslo.config option (example on current master: [DEFAULT]/property_protection_file). These options should be updated with the better documentation before automatic syncing takes place. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1411836/+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 1411837] Re: Owner id for image in admin images page is no user friendly
** Attachment added: image_tables.png https://bugs.launchpad.net/horizon/+bug/1411837/+attachment/4300218/+files/image_tables.png ** Changed in: horizon Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1411837 Title: Owner id for image in admin images page is no user friendly Status in OpenStack Dashboard (Horizon): Invalid Bug description: Now, in admin images page, the images table show owner id for image, and this is not user friendly To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1411837/+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 1411837] [NEW] Owner id for image in admin images page is no user friendly
Public bug reported: Now, in admin images page, the images table show owner id for image, and this is not user friendly ** Affects: horizon Importance: Undecided Status: Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1411837 Title: Owner id for image in admin images page is no user friendly Status in OpenStack Dashboard (Horizon): Invalid Bug description: Now, in admin images page, the images table show owner id for image, and this is not user friendly To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1411837/+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 1411849] [NEW] No message is prompted when Gateway IP is set to IPv4 address and IP version as IPv6 in 'Create Network' window
Public bug reported: Steps to reproduce: 1. Login to horizon dashboard. 2. Navigate to Network Topology under Network and select 'Create Network' button. 3. On the pop up window, provide network name and click next. 4. In Subnet window, provide a Subnet Name, valid Network address , select IP Version as IPv6 , set the Gateway IP address with a valid IPv4 address and click Next Current output: No message is prompted to the user to correct the problem in the particular field and Next button simply highlights the Create Subnet checkbox. Expected output: Useful message should be displayed near the field prompting the user to correct the IP address. ** Affects: horizon Importance: Undecided Assignee: Sripriya (sseetha) Status: New ** Tags: neutron ** Changed in: horizon Assignee: (unassigned) = Sripriya (sseetha) ** Summary changed: - No error message is prompted when Gateway IP is set to IPv4 address and IP version as IPv6 in 'Create Network' window + No message is prompted when Gateway IP is set to IPv4 address and IP version as IPv6 in 'Create Network' window -- 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/1411849 Title: No message is prompted when Gateway IP is set to IPv4 address and IP version as IPv6 in 'Create Network' window Status in OpenStack Dashboard (Horizon): New Bug description: Steps to reproduce: 1. Login to horizon dashboard. 2. Navigate to Network Topology under Network and select 'Create Network' button. 3. On the pop up window, provide network name and click next. 4. In Subnet window, provide a Subnet Name, valid Network address , select IP Version as IPv6 , set the Gateway IP address with a valid IPv4 address and click Next Current output: No message is prompted to the user to correct the problem in the particular field and Next button simply highlights the Create Subnet checkbox. Expected output: Useful message should be displayed near the field prompting the user to correct the IP address. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1411849/+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 1411847] [NEW] block device mapping transformation doesn't handle image source
Public bug reported: I hit this while implementing volume snapshots for the NFS Cinder driver. I booted an instance from an image with the destination as a volume. nova boot --block-device id=fc19829e-5f65-4e9c- acf3-0e898747506f,source=image,dest=volume,size=2,bootindex=0,shutdown=preserve ... Creating a volume snapshot for this case will run down _volume_refresh_connection_info in LibvirtDriver, which fails in DriverVolumeBlockDevice's _transform, which only allows 'volume' as a source type. It looks to me like this code should allow 'image' as a source, but I'm not an expert in this area in Nova... ** Affects: nova Importance: Undecided Assignee: Eric Harney (eharney) Status: In Progress ** Changed in: nova Status: New = In Progress ** Changed in: nova Assignee: (unassigned) = Eric Harney (eharney) -- 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/1411847 Title: block device mapping transformation doesn't handle image source Status in OpenStack Compute (Nova): In Progress Bug description: I hit this while implementing volume snapshots for the NFS Cinder driver. I booted an instance from an image with the destination as a volume. nova boot --block-device id=fc19829e-5f65-4e9c- acf3-0e898747506f,source=image,dest=volume,size=2,bootindex=0,shutdown=preserve ... Creating a volume snapshot for this case will run down _volume_refresh_connection_info in LibvirtDriver, which fails in DriverVolumeBlockDevice's _transform, which only allows 'volume' as a source type. It looks to me like this code should allow 'image' as a source, but I'm not an expert in this area in Nova... To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1411847/+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 1411865] [NEW] pylint is failing in the check queue
Public bug reported: I'm getting a pylint error on my newest patch [2] that doesn't seem to be related to the patch. I seem to get the same error on master. Logstash is hinting at something starting to go wrong [1]. Possible unbalanced tuple unpacking with sequence defined at line 153: left side has 2 label(s), right side has 0 value(s) (unbalanced-tuple- unpacking) [1] http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwidW5iYWxhbmNlZCB0dXBsZSB1bnBhY2tpbmdcIiBBTkQgdGFnczpcImNvbnNvbGVcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyMTQ0NzYyMTc4MiwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ== [2]https://review.openstack.org/#/c/147972 ** Affects: neutron Importance: Undecided Status: New ** Description changed: I'm getting a pylint error on my newest patch [2] that doesn't seem to - be related. I seem to get the same error on master. Logstash is - hinting at something starting to go wrong. + be related to the patch. I seem to get the same error on master. + Logstash is hinting at something starting to go wrong [1]. Possible unbalanced tuple unpacking with sequence defined at line 153: left side has 2 label(s), right side has 0 value(s) (unbalanced-tuple- unpacking) - [1] http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwidW5iYWxhbmNlZCB0dXBsZSB1bnBhY2tpbmdcIiBBTkQgdGFnczpcImNvbnNvbGVcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyMTQ0NzYyMTc4MiwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ== + [1] http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwidW5iYWxhbmNlZCB0dXBsZSB1bnBhY2tpbmdcIiBBTkQgdGFnczpcImNvbnNvbGVcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyMTQ0NzYyMTc4MiwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ== [2]https://review.openstack.org/#/c/147972 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1411865 Title: pylint is failing in the check queue Status in OpenStack Neutron (virtual network service): New Bug description: I'm getting a pylint error on my newest patch [2] that doesn't seem to be related to the patch. I seem to get the same error on master. Logstash is hinting at something starting to go wrong [1]. Possible unbalanced tuple unpacking with sequence defined at line 153: left side has 2 label(s), right side has 0 value(s) (unbalanced- tuple-unpacking) [1] http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwidW5iYWxhbmNlZCB0dXBsZSB1bnBhY2tpbmdcIiBBTkQgdGFnczpcImNvbnNvbGVcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyMTQ0NzYyMTc4MiwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ== [2]https://review.openstack.org/#/c/147972 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1411865/+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 1411874] [NEW] DVR router is seen on multiple controller nodes
Public bug reported:
I have Openstack deployed with DVR support.
I did following to setup my networks
neutron net-create demo-net
netdemoaid=$(neutron net-list | awk '{if($4=='demo-net'){print $2;}}')
neutron subnet-create demo-net 10.100.102.0/24 --name demo-subnet
subnetdemoid=$(neutron subnet-list | awk '{if($4=='demo-subnet'){print $2;}}')
neutron router-create demo-router
routerdemoid=$(neutron router-list | awk '{if($4=='demo-router'){print $2;}}')
exnetid=$(neutron net-list | awk '{if($4=='ext-net'){print $2;}}')
neutron router-gateway-set $routerdemoid $exnetid
neutron router-interface-add demo-router $subnetdemoid
root@Linux:/tmp# neutron l3-agent-list-hosting-router
9182ecba-00ac-42ce-b0d1-801003bb1b14
+--+--++---+
| id | host
| admin_state_up | alive |
+--+--++---+
| 2d6505ef-e7a5-4672-a040-3a50f764a193 | controller-controller1-25ic4624koca |
True | :-) |
+--+--++---+
Then I boot an instance:
nova boot --image cirros --flavor m1.tiny --key-name default --nic
net-id=$netdemoid cirrosinstance
root@Linux:/tmp# neutron l3-agent-list-hosting-router
9182ecba-00ac-42ce-b0d1-801003bb1b14
+--+-++---+
| id | host
| admin_state_up | alive |
+--+-++---+
| 2d6505ef-e7a5-4672-a040-3a50f764a193 | controller-controller1-25ic4624koca
| True | :-) |
| 339eb96b-9c9d-400a-a45f-e0f2ed6ebf2e | controller-controller0-twwogbnv
| True | :-) |
| 6b1cc42d-f701-47ba-a0fc-661fb3bc22ae | novacompute2-novacompute2-b4jb7jtppnas
| True | :-) |
| fdffb433-b5f6-4d10-bdc4-2030a9800b2a | controller-controller2-7piq4lqrgtma
| True | :-) |
+--+-++---+
We have qrouter binded to three controllers instead of just one controller.
We have qrouter binded to novacompute2 because we have DVR enabled, and
instance is on this compute node.
Look at ip netns, only have SNAT on controller1
DHCP servers for subnetdemo are running on controller0 and controller2
We only need qrouter bind to one controller, not three controllers.
** 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/1411874
Title:
DVR router is seen on multiple controller nodes
Status in OpenStack Neutron (virtual network service):
New
Bug description:
I have Openstack deployed with DVR support.
I did following to setup my networks
neutron net-create demo-net
netdemoaid=$(neutron net-list | awk '{if($4=='demo-net'){print $2;}}')
neutron subnet-create demo-net 10.100.102.0/24 --name demo-subnet
subnetdemoid=$(neutron subnet-list | awk '{if($4=='demo-subnet'){print
$2;}}')
neutron router-create demo-router
routerdemoid=$(neutron router-list | awk '{if($4=='demo-router'){print
$2;}}')
exnetid=$(neutron net-list | awk '{if($4=='ext-net'){print $2;}}')
neutron router-gateway-set $routerdemoid $exnetid
neutron router-interface-add demo-router $subnetdemoid
root@Linux:/tmp# neutron l3-agent-list-hosting-router
9182ecba-00ac-42ce-b0d1-801003bb1b14
+--+--++---+
| id | host
| admin_state_up | alive |
+--+--++---+
| 2d6505ef-e7a5-4672-a040-3a50f764a193 | controller-controller1-25ic4624koca
| True | :-) |
+--+--++---+
Then I boot an instance:
nova boot --image cirros --flavor m1.tiny --key-name default --nic
net-id=$netdemoid cirrosinstance
root@Linux:/tmp# neutron l3-agent-list-hosting-router
9182ecba-00ac-42ce-b0d1-801003bb1b14
+--+-++---+
| id | host
| admin_state_up | alive |
[Yahoo-eng-team] [Bug 1411883] [NEW] DVR qrouters are not created when VMs are added after the router-interface is added to the router
Public bug reported:
qrouters for DVR routers should be created on demand when VMs are
created on the compute Node.
But with the current code, it seems that is broken.
When a VM is created on a router's subnet after the router-interface is
added to the router, then the 'qrouter' namespace is not created on the
compute Node. It is only created on the dvr_snat node and not on the
dvr node.
stack@ubuntu-multinet-ctlr:~/devstack$ neutron net-create net1
Created a new network:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| ccaeaf39-4c33-40b8-b0e0-551414a86ca3 |
| name | net1 |
| provider:network_type | vxlan|
| provider:physical_network | |
| provider:segmentation_id | 1003 |
| router:external | False|
| shared| False|
| status| ACTIVE |
| subnets | |
| tenant_id | f822fe0773cd4d21bddb4ecb2477f21d |
+---+--+
stack@ubuntu-multinet-ctlr:~/devstack$ neutron subnet-create net1 --name
subnet1 10.20.0.0/24
Created a new subnet:
+---+--+
| Field | Value|
+---+--+
| allocation_pools | {start: 10.20.0.2, end: 10.20.0.254} |
| cidr | 10.20.0.0/24 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip| 10.20.0.1|
| host_routes | |
| id| e404b9cb-dd2d-4919-8b6c-72799ae7efed |
| ip_version| 4|
| ipv6_address_mode | |
| ipv6_ra_mode | |
| name | subnet1 |
| network_id| ccaeaf39-4c33-40b8-b0e0-551414a86ca3 |
| tenant_id | f822fe0773cd4d21bddb4ecb2477f21d |
+---+--+
stack@ubuntu-multinet-ctlr:~/devstack$ neutron router-create router2
Created a new router:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| distributed | True |
| external_gateway_info | |
| ha| False|
| id| e82022cd-d45c-4558-9d35-86a1e5f58462 |
| name | router2 |
| routes| |
| status| ACTIVE |
| tenant_id | f822fe0773cd4d21bddb4ecb2477f21d |
+---+--+
stack@ubuntu-multinet-ctlr:~/devstack$ neutron router-interface-add router2
subnet1
Added interface f872d6ea-f2c9-4334-8090-48d9542cdbef to router router2.
stack@ubuntu-multinet-ctlr:~/devstack$ neutron router-gateway-set router2
publicSet gateway for router router2
stack@ubuntu-multinet-ctlr:~/devstack$
stack@ubuntu-multinet-ctlr:~/devstack$
stack@ubuntu-multinet-ctlr:~/devstack$ sudo ip netns list
qrouter-e82022cd-d45c-4558-9d35-86a1e5f58462
qdhcp-5f413f3e-573f-404d-9d24-b7b11b141278
snat-acfc7720-3071-46a3-8be3-1b9430ddb47e
qrouter-acfc7720-3071-46a3-8be3-1b9430ddb47e
stack@ubuntu-multinet-ctlr:~/devstack$ sudo ip netns list
snat-e82022cd-d45c-4558-9d35-86a1e5f58462
qrouter-e82022cd-d45c-4558-9d35-86a1e5f58462
qdhcp-5f413f3e-573f-404d-9d24-b7b11b141278
snat-acfc7720-3071-46a3-8be3-1b9430ddb47e
qrouter-acfc7720-3071-46a3-8be3-1b9430ddb47e
stack@ubuntu-multinet-ctlr:~/devstack$ sudo ip netns list
snat-e82022cd-d45c-4558-9d35-86a1e5f58462
qrouter-e82022cd-d45c-4558-9d35-86a1e5f58462
qdhcp-5f413f3e-573f-404d-9d24-b7b11b141278
snat-acfc7720-3071-46a3-8be3-1b9430ddb47e
qrouter-acfc7720-3071-46a3-8be3-1b9430ddb47e
stack@ubuntu-multinet-ctlr:~/devstack$ nova boot --flavor 42 --image
cirros-0.3.2-x86_64-uec --nic
[Yahoo-eng-team] [Bug 1411892] [NEW] JS keyup/keydown making user create very difficult
Public bug reported: The users table (/identity/users/) in a particular environment displays 800+ users on the page. I click Create User and the modal dialog pops up. When I start entering User Name, with every character that is entered, there is a pause of 4-5 seconds. Data entry is practically unusable. When I tested this against a local devstack instance, there is no such behavior. I then tested this against an environment that has ~200 users. The issue re-occurred, but wasn't as severe as the initial environment, leading me to conclude that the number of users was affecting the form behavior. I started digging in a bit deeper and found that the page invokes a couple of javascript functions in the horizon.tabs.js file intended to enable keyboard navigation between tabs in a form. The issue is not noticeable on a page with a small DOM, but gets worse and worse the more DOM elements are on the page. The issue is that the JS code goes thru every DOM element on the page on keyup/keydown. ** Affects: horizon Importance: Undecided Assignee: Chris Johnson (wchrisjohnson) Status: New ** Tags: ux ** Changed in: horizon Assignee: (unassigned) = Chris Johnson (wchrisjohnson) ** Tags added: ux -- 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/1411892 Title: JS keyup/keydown making user create very difficult Status in OpenStack Dashboard (Horizon): New Bug description: The users table (/identity/users/) in a particular environment displays 800+ users on the page. I click Create User and the modal dialog pops up. When I start entering User Name, with every character that is entered, there is a pause of 4-5 seconds. Data entry is practically unusable. When I tested this against a local devstack instance, there is no such behavior. I then tested this against an environment that has ~200 users. The issue re-occurred, but wasn't as severe as the initial environment, leading me to conclude that the number of users was affecting the form behavior. I started digging in a bit deeper and found that the page invokes a couple of javascript functions in the horizon.tabs.js file intended to enable keyboard navigation between tabs in a form. The issue is not noticeable on a page with a small DOM, but gets worse and worse the more DOM elements are on the page. The issue is that the JS code goes thru every DOM element on the page on keyup/keydown. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1411892/+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 1409467] Re: Add ssh hyperlink to instance IP addresses
I'm proposing this change in a blueprint. ** Changed in: horizon Status: In Progress = Invalid ** Changed in: horizon Assignee: Jeffrey Olsen (jeffrey-olsen) = (unassigned) -- 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/1409467 Title: Add ssh hyperlink to instance IP addresses Status in OpenStack Dashboard (Horizon): Invalid Bug description: Wish list request: Add a hyperlink to deployed instances private and public IP addresses that can open an SSH terminal To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1409467/+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
