[Yahoo-eng-team] [Bug 1529913] Re: use warning to avoid DeprecationWarning
** Also affects: keystone Importance: Undecided Status: New ** Changed in: keystone Assignee: (unassigned) => Ankit Agrawal (ankitagrawal) ** Also affects: nova Importance: Undecided Status: New ** Also affects: manila Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1529913 Title: use warning to avoid DeprecationWarning Status in Glance: In Progress Status in OpenStack Identity (keystone): New Status in Manila: New Status in OpenStack Compute (nova): New Bug description: Python 3 deprecated the logger.warn method, see: https://docs.python.org/3/library/logging.html#logging.warning so we prefer to use warning to avoid DeprecationWarning. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1529913/+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 1529215] Re: "Description" form is not a textarea in Create or Update Image dialog
Reviewed: https://review.openstack.org/261468 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=307b2af8ac26177b7c92182f50b00efc4164786b Submitter: Jenkins Branch:master commit 307b2af8ac26177b7c92182f50b00efc4164786b Author: kenji-ishii Date: Wed Dec 23 12:57:30 2015 +0900 Modify description form in Create or Update Image dialog In Create or Update Image dialog, there have "description" form. Currently it is not a textarea but it should be a textarea. Change-Id: I80bb9e6ea784fb51609613a3a5868943cb086644 Closes-bug: #1529215 ** 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/1529215 Title: "Description" form is not a textarea in Create or Update Image dialog Status in OpenStack Dashboard (Horizon): Fix Released Bug description: In Create or Update Image dialog, there have "description" form. Currently it is not a textarea but it should be a textarea. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1529215/+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 1530070] [NEW] Neutron Netns Cleanup script fails to delete namespaces after reboot
Public bug reported: After rebooting a node which held an active VRRP router, DHCP , and metadata agent, the neutron-netns-cleanup utility failed to delete stale namespaces. The utility fails with : seting the network namespace "qrouter-3d4e5634-59f0-401e- 9f28-6c8daaec311c" failed: Invalid argument The reason is a bug in iproute which fails to do any operation on a stale namespaces which appear in /var/run/netns like this: root@stratonode66 ~# ls -l /var/run/netns/ total 0 rrr- 1 root root 0 Dec 24 13:38 qdhcp-0a348422-97e2-4ab6-bb22-55994a125823 rrr- 1 root root 0 Dec 24 11:54 qdhcp-2258aa3f-d256-4c9f-9e48-16811fc57981 rrr- 1 root root 0 Dec 24 13:38 qdhcp-3ceb1f27-e3fc-413a-a184-567041f073e2 rrr- 1 root root 0 Dec 24 11:54 qdhcp-62a51b66-d0e2-42fc-bdf2-2d622a889e75 rrr- 1 root root 0 Dec 24 11:54 qdhcp-81b550a2-c483-4280-a83a-b560ecdc416b -- 1 root root 0 Dec 23 13:54 qrouter-3d4e5634-59f0-401e-9f28-6c8daaec311c -- 1 root root 0 Dec 24 11:25 qrouter-69d20923-da78-4c6b-bb24-967dd67acb1d -- 1 root root 0 Dec 23 13:54 qrouter-cc649801-96ec-4d59-90de-1004fc026024 This bug s related, but doesn't solve the issue after reboot: https://bugs.launchpad.net/neutron/+bug/1052535. I solved it by fixing the neutron-netns-cleanup --force code, with this patch: diff --git a/neutron/agent/netns_cleanup_util.py b/neutron/agent/netns_cleanup_util.py index 771a77f..3c43480 100644 --- a/neutron/agent/netns_cleanup_util.py +++ b/neutron/agent/netns_cleanup_util.py @@ -132,8 +132,13 @@ def destroy_namespace(conf, namespace, force=False): # NOTE: The dhcp driver will remove the namespace if is it empty, # so a second check is required here. if ip.netns.exists(namespace): -for device in ip.get_devices(exclude_loopback=True): -unplug_device(conf, device) +try: +for device in ip.get_devices(exclude_loopback=True): +unplug_device(conf, device) +except RuntimeError: +LOG.info(_('Keep calm, and destroy namespace: %s'), namespace) +ip.netns.delete(namespace) +return ip.garbage_collect_namespace() except Exception: When I run the following after reboot, the name spaces are cleaned-up and when starting neutron-openvswitch-agent.service neutron-dhcp- agent.service neutron-l3-agent.service they are recreated. ** 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/1530070 Title: Neutron Netns Cleanup script fails to delete namespaces after reboot Status in neutron: New Bug description: After rebooting a node which held an active VRRP router, DHCP , and metadata agent, the neutron-netns-cleanup utility failed to delete stale namespaces. The utility fails with : seting the network namespace "qrouter-3d4e5634-59f0-401e- 9f28-6c8daaec311c" failed: Invalid argument The reason is a bug in iproute which fails to do any operation on a stale namespaces which appear in /var/run/netns like this: root@stratonode66 ~# ls -l /var/run/netns/ total 0 rrr- 1 root root 0 Dec 24 13:38 qdhcp-0a348422-97e2-4ab6-bb22-55994a125823 rrr- 1 root root 0 Dec 24 11:54 qdhcp-2258aa3f-d256-4c9f-9e48-16811fc57981 rrr- 1 root root 0 Dec 24 13:38 qdhcp-3ceb1f27-e3fc-413a-a184-567041f073e2 rrr- 1 root root 0 Dec 24 11:54 qdhcp-62a51b66-d0e2-42fc-bdf2-2d622a889e75 rrr- 1 root root 0 Dec 24 11:54 qdhcp-81b550a2-c483-4280-a83a-b560ecdc416b -- 1 root root 0 Dec 23 13:54 qrouter-3d4e5634-59f0-401e-9f28-6c8daaec311c -- 1 root root 0 Dec 24 11:25 qrouter-69d20923-da78-4c6b-bb24-967dd67acb1d -- 1 root root 0 Dec 23 13:54 qrouter-cc649801-96ec-4d59-90de-1004fc026024 This bug s related, but doesn't solve the issue after reboot: https://bugs.launchpad.net/neutron/+bug/1052535. I solved it by fixing the neutron-netns-cleanup --force code, with this patch: diff --git a/neutron/agent/netns_cleanup_util.py b/neutron/agent/netns_cleanup_util.py index 771a77f..3c43480 100644 --- a/neutron/agent/netns_cleanup_util.py +++ b/neutron/agent/netns_cleanup_util.py @@ -132,8 +132,13 @@ def destroy_namespace(conf, namespace, force=False): # NOTE: The dhcp driver will remove the namespace if is it empty, # so a second check is required here. if ip.netns.exists(namespace): -for device in ip.get_devices(exclude_loopback=True): -unplug_device(conf, device) +try: +for device in ip.get_devices(exclude_loopback=True): +unplug_device(conf, device) +except RuntimeError: +LOG.info(_('Keep calm, and destroy namesp
[Yahoo-eng-team] [Bug 1467589] Re: Remove Cinder V1 support
Even though we fix this issue in devstack and openstackclient , there are still some cases where devstack is using Cinder v1 API, this is duo to os-config-client's default config file is using v1 api endpoint. openstackclient get the cloud endpoint through os-config-client. Please take a look at this fix https://review.openstack.org/#/c/261787/ ** Also affects: os-client-config Importance: Undecided Status: New ** Changed in: os-client-config Assignee: (unassigned) => Yaguang Tang (heut2008) -- 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/1467589 Title: Remove Cinder V1 support Status in Cinder: Won't Fix Status in devstack: In Progress Status in grenade: In Progress Status in heat: Confirmed Status in OpenStack Compute (nova): In Progress Status in os-client-config: New Status in python-openstackclient: Fix Released Status in Rally: Fix Released Status in tempest: In Progress Bug description: Cinder created v2 support in the Grizzly release. This is to track progress in removing v1 support in other projects. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1467589/+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 1530091] [NEW] check for mandatory parameter 'size' in schema/volumes.py missing for create
Public bug reported: 1. Version of NOVA 12.0.1 2. NA 3. a). Try to Create volume without giving size as input parameter. b). Request failed. c). Response body have message---"message": "Invalid input received: Invalid input received: Volume size 'None' must be an integer and greater than 0 (HTTP 400)- Unexpected. d). Error message is not clear. Expected Result: 5. Error message should be "'size' is a required property" it will give clear understanding that you cant skip the size parameter. ** Affects: nova Importance: Undecided Assignee: Piyush Pathak (cyperxprt) Status: New ** Tags: compute ** Changed in: nova Assignee: (unassigned) => Piyush Pathak (cyperxprt) -- 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/1530091 Title: check for mandatory parameter 'size' in schema/volumes.py missing for create Status in OpenStack Compute (nova): New Bug description: 1. Version of NOVA 12.0.1 2. NA 3. a). Try to Create volume without giving size as input parameter. b). Request failed. c). Response body have message---"message": "Invalid input received: Invalid input received: Volume size 'None' must be an integer and greater than 0 (HTTP 400)- Unexpected. d). Error message is not clear. Expected Result: 5. Error message should be "'size' is a required property" it will give clear understanding that you cant skip the size parameter. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1530091/+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 1495862] Re: admin image table have no tenant_name when UpdateRow
Reviewed: https://review.openstack.org/223554 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=cc84199c8798d66fb910a5edb4e4497c8f27b2ca Submitter: Jenkins Branch:master commit cc84199c8798d66fb910a5edb4e4497c8f27b2ca Author: zhu.rong Date: Tue Sep 15 20:03:47 2015 +0800 Fix no tenant name in admin image panel when UpdateRow Steps for reproduce: Login to Horizon as an admin user Navigate to Admin--System--Images Click the Create Image button, upload a large image from a HTTP URL then will see the uploading image's project name is null. Co-Authored-By:zhangguoqing Change-Id: If10c3eb1bb5fa67c363ce9c6c514e2cd018de073 Closes-Bug: #1495862 ** 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/1495862 Title: admin image table have no tenant_name when UpdateRow Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Admin Images table when the image have UpdateRow action, it will give the message: The attribute tenant_name doesn't exist on Steps for reproduce: Login to Horizon as an admin user Navigate to Admin--System--Images Click the Create Image button, upload a large image from a HTTP URL then will see the uploading image's project name is null. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1495862/+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 1529913] Re: use warning to avoid DeprecationWarning
** Also affects: horizon Importance: Undecided Status: New ** Changed in: horizon Assignee: (unassigned) => LiuNanke (nanke-liu) ** Changed in: horizon 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/1529913 Title: use warning to avoid DeprecationWarning Status in Glance: In Progress Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): New Status in Manila: New Status in OpenStack Compute (nova): New Bug description: Python 3 deprecated the logger.warn method, see: https://docs.python.org/3/library/logging.html#logging.warning so we prefer to use warning to avoid DeprecationWarning. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1529913/+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 1529913] Re: use warning to avoid DeprecationWarning
** No longer affects: horizon -- 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/1529913 Title: use warning to avoid DeprecationWarning Status in Glance: In Progress Status in OpenStack Identity (keystone): In Progress Status in Manila: New Status in OpenStack Compute (nova): New Bug description: Python 3 deprecated the logger.warn method, see: https://docs.python.org/3/library/logging.html#logging.warning so we prefer to use warning to avoid DeprecationWarning. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1529913/+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 1290234] Re: do not use __builtin__ in Python3
** Also affects: bandit Importance: Undecided Status: New ** Changed in: bandit Assignee: (unassigned) => Shuquan Huang (shuquan) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1290234 Title: do not use __builtin__ in Python3 Status in Bandit: In Progress Status in Glance: Fix Released Status in heat: Triaged Status in Ironic: Fix Released Status in neutron: In Progress Status in Trove: In Progress Status in tuskar: Fix Released Bug description: __builtin__ does not exist in Python 3, use six.moves.builtins instead. To manage notifications about this bug go to: https://bugs.launchpad.net/bandit/+bug/1290234/+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 1290234] Re: do not use __builtin__ in Python3
** Also affects: magnum Importance: Undecided Status: New ** Changed in: magnum Assignee: (unassigned) => Shuquan Huang (shuquan) ** Also affects: octavia Importance: Undecided Status: New ** Changed in: octavia Assignee: (unassigned) => Shuquan Huang (shuquan) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1290234 Title: do not use __builtin__ in Python3 Status in Bandit: In Progress Status in Glance: Fix Released Status in heat: Triaged Status in Ironic: Fix Released Status in Magnum: In Progress Status in neutron: In Progress Status in octavia: In Progress Status in Trove: In Progress Status in tuskar: Fix Released Bug description: __builtin__ does not exist in Python 3, use six.moves.builtins instead. To manage notifications about this bug go to: https://bugs.launchpad.net/bandit/+bug/1290234/+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 1290234] Re: do not use __builtin__ in Python3
** Also affects: nova Importance: Undecided Status: New ** Changed in: nova Assignee: (unassigned) => Abhishek Kekane (abhishek-kekane) ** Also affects: keystone Importance: Undecided Status: New ** Changed in: keystone Assignee: (unassigned) => Abhishek Kekane (abhishek-kekane) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1290234 Title: do not use __builtin__ in Python3 Status in Bandit: In Progress Status in Glance: Fix Released Status in heat: Triaged Status in Ironic: Fix Released Status in OpenStack Identity (keystone): New Status in Magnum: In Progress Status in neutron: In Progress Status in OpenStack Compute (nova): New Status in octavia: In Progress Status in Trove: In Progress Status in tuskar: Fix Released Bug description: __builtin__ does not exist in Python 3, use six.moves.builtins instead. To manage notifications about this bug go to: https://bugs.launchpad.net/bandit/+bug/1290234/+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 1529836] Re: Fix deprecated library function (os.popen()).
** Also affects: manila Importance: Undecided Status: New ** Changed in: manila Assignee: (unassigned) => Abhishek Kekane (abhishek-kekane) ** Also affects: cinder Importance: Undecided Status: New ** Changed in: cinder Assignee: (unassigned) => Abhishek Kekane (abhishek-kekane) ** Also affects: keystone Importance: Undecided Status: New ** Changed in: keystone Assignee: (unassigned) => Abhishek Kekane (abhishek-kekane) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1529836 Title: Fix deprecated library function (os.popen()). Status in Cinder: New Status in devstack: In Progress Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): New Status in Manila: New Status in neutron: In Progress Status in OpenStack Compute (nova): In Progress Status in oslo-incubator: In Progress Status in OpenStack Object Storage (swift): In Progress Status in tempest: In Progress Bug description: Deprecated library function os.popen is still in use at some places. Need to replace it using subprocess module. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1529836/+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 1529913] Re: use warning to avoid DeprecationWarning
** Also affects: horizon Importance: Undecided Status: New ** Changed in: horizon Assignee: (unassigned) => LiuNanke (nanke-liu) ** Changed in: horizon Status: New => In Progress ** Also affects: trove Importance: Undecided Status: New ** Changed in: trove Assignee: (unassigned) => LiuNanke (nanke-liu) ** Changed in: trove 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/1529913 Title: use warning to avoid DeprecationWarning Status in Glance: In Progress Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in Manila: New Status in OpenStack Compute (nova): In Progress Status in Trove: In Progress Bug description: Python 3 deprecated the logger.warn method, see: https://docs.python.org/3/library/logging.html#logging.warning so we prefer to use warning to avoid DeprecationWarning. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1529913/+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 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()
** Also affects: ironic-python-agent Importance: Undecided Status: New ** Changed in: ironic-python-agent Assignee: (unassigned) => Shuquan Huang (shuquan) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1268480 Title: assertTrue(isinstance()) in tests should be replace with assertIsInstance() Status in Ceilometer: Fix Released Status in Cinder: Opinion Status in Glance: Fix Released Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: In Progress Status in OpenStack Identity (keystone): Fix Released Status in neutron: Invalid Status in OpenStack Compute (nova): Fix Released Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-glanceclient: Fix Released Status in python-keystoneclient: Fix Released Status in python-novaclient: Fix Released Status in tempest: New Bug description: some of tests use different method of assertTrue(isinstance(A, B)) or assertEqual(type(A), B). The correct way is to use assertIsInstance(A, B) provided by testtools To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1268480/+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 1529534] Re: User new log style where Logger.exception() is used by passing an exception object as the first argument.
** Also affects: cinder Importance: Undecided Status: New ** Changed in: cinder Status: New => In Progress ** Changed in: cinder Assignee: (unassigned) => LiuNanke (nanke-liu) -- 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/1529534 Title: User new log style where Logger.exception() is used by passing an exception object as the first argument. Status in Ceilometer: New Status in Cinder: In Progress Status in Gnocchi: In Progress Status in Ironic: In Progress Status in Magnum: In Progress Status in Manila: In Progress Status in OpenStack Compute (nova): In Progress Status in python-ceilometerclient: New Status in python-glanceclient: New Status in python-gnocchiclient: In Progress Status in python-keystoneclient: New Status in python-neutronclient: Confirmed Status in python-troveclient: New Status in Sahara: New Status in Trove: New Bug description: Use new log style where Logger.exception() is used by passing an exception object as the first argument[1]. [1]http://docs.openstack.org/developer/oslo.log/usage.html#no-more- implicit-conversion-to-unicode-str To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1529534/+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 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()
** Also affects: tempest Importance: Undecided Status: New ** Changed in: tempest Assignee: (unassigned) => Shuquan Huang (shuquan) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1268480 Title: assertTrue(isinstance()) in tests should be replace with assertIsInstance() Status in Ceilometer: Fix Released Status in Cinder: Opinion Status in Glance: Fix Released Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: In Progress Status in OpenStack Identity (keystone): Fix Released Status in neutron: Invalid Status in OpenStack Compute (nova): Fix Released Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-glanceclient: Fix Released Status in python-keystoneclient: Fix Released Status in python-novaclient: Fix Released Status in tempest: In Progress Bug description: some of tests use different method of assertTrue(isinstance(A, B)) or assertEqual(type(A), B). The correct way is to use assertIsInstance(A, B) provided by testtools To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1268480/+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 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()
** Also affects: barbican Importance: Undecided Status: New ** Changed in: barbican Assignee: (unassigned) => Shuquan Huang (shuquan) -- 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/1268480 Title: assertTrue(isinstance()) in tests should be replace with assertIsInstance() Status in Barbican: In Progress Status in Ceilometer: Fix Released Status in Cinder: Opinion Status in CloudRoast: New Status in Glance: Fix Released Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: In Progress Status in OpenStack Identity (keystone): Fix Released Status in neutron: Invalid Status in OpenStack Compute (nova): Fix Released Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-glanceclient: Fix Released Status in python-keystoneclient: Fix Released Status in python-novaclient: Fix Released Status in tempest: In Progress Bug description: some of tests use different method of assertTrue(isinstance(A, B)) or assertEqual(type(A), B). The correct way is to use assertIsInstance(A, B) provided by testtools To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1268480/+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 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()
** Also affects: cloudroast Importance: Undecided Status: New ** Changed in: cloudroast Assignee: (unassigned) => Shuquan Huang (shuquan) -- 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/1268480 Title: assertTrue(isinstance()) in tests should be replace with assertIsInstance() Status in Barbican: In Progress Status in Ceilometer: Fix Released Status in Cinder: In Progress Status in CloudRoast: New Status in Glance: Fix Released Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: In Progress Status in OpenStack Identity (keystone): Fix Released Status in neutron: Invalid Status in OpenStack Compute (nova): Fix Released Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-glanceclient: Fix Released Status in python-keystoneclient: Fix Released Status in python-novaclient: Fix Released Status in tempest: In Progress Bug description: some of tests use different method of assertTrue(isinstance(A, B)) or assertEqual(type(A), B). The correct way is to use assertIsInstance(A, B) provided by testtools To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1268480/+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 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()
Fix proposed to branch: master Review: https://review.openstack.org/262540 ** Changed in: cinder Status: Opinion => In Progress ** Changed in: cinder Assignee: Liusheng (liusheng) => Shuquan Huang (shuquan) -- 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/1268480 Title: assertTrue(isinstance()) in tests should be replace with assertIsInstance() Status in Barbican: In Progress Status in Ceilometer: Fix Released Status in Cinder: In Progress Status in CloudRoast: New Status in Glance: Fix Released Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: In Progress Status in OpenStack Identity (keystone): Fix Released Status in neutron: Invalid Status in OpenStack Compute (nova): Fix Released Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-glanceclient: Fix Released Status in python-keystoneclient: Fix Released Status in python-novaclient: Fix Released Status in tempest: In Progress Bug description: some of tests use different method of assertTrue(isinstance(A, B)) or assertEqual(type(A), B). The correct way is to use assertIsInstance(A, B) provided by testtools To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1268480/+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 1529836] Re: Fix deprecated library function (os.popen()).
** Changed in: manila Assignee: Abhishek Kekane (abhishek-kekane) => Harshada Mangesh Kakad (harshada-kakad) ** Changed in: cinder Assignee: Abhishek Kekane (abhishek-kekane) => Harshada Mangesh Kakad (harshada-kakad) ** Changed in: keystone Assignee: Abhishek Kekane (abhishek-kekane) => Harshada Mangesh Kakad (harshada-kakad) ** Changed in: cinder Status: New => In Progress ** Changed in: manila Status: New => In Progress ** Changed in: keystone Status: New => In Progress ** Also affects: glance Importance: Undecided Status: New ** Changed in: glance Assignee: (unassigned) => Harshada Mangesh Kakad (harshada-kakad) ** Changed in: glance Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1529836 Title: Fix deprecated library function (os.popen()). Status in Cinder: In Progress Status in devstack: In Progress Status in Glance: In Progress Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in Manila: In Progress Status in neutron: In Progress Status in OpenStack Compute (nova): In Progress Status in oslo-incubator: In Progress Status in OpenStack Object Storage (swift): In Progress Status in tempest: In Progress Bug description: Deprecated library function os.popen is still in use at some places. Need to replace it using subprocess module. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1529836/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1528393] Re: signature_utils tests fail on Fedora/RHEL/CentOS because not all ECC curves are available
Reviewed: https://review.openstack.org/260277 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=291e71990a0866836d1becea6d519df9abaaa186 Submitter: Jenkins Branch:master commit 291e71990a0866836d1becea6d519df9abaaa186 Author: Mark McLoughlin Date: Mon Dec 21 23:54:17 2015 + signature_utils: handle ECC curve unavailability Some ECC curves are unavailable on some platforms (like Fedora, RHEL, and CentOS) because of legal concerns. See the bug report for more details and history. The cryptography backend has a elliptic_curve_supported() method which we can use to avoid curves which are unavailable on the current platform. If an image signature uses one of these curves, we will return an "Invalid signature key type" error. Use the warnings module in the unit tests to avoid silently ignoring this issue during testing. This warning will be captured from the test's stderr and reported by testr. Closes-Bug: #1528393 Change-Id: Ie25311c48b276f300fadaf1815fc4df4cb89cf8d Signed-off-by: Mark McLoughlin ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1528393 Title: signature_utils tests fail on Fedora/RHEL/CentOS because not all ECC curves are available Status in OpenStack Compute (nova): Fix Released Bug description: Not all ECC curves we use in signature_utils are available on all platforms - e.g. On RHEL 7.2 $ openssl ecparam -list_curves secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field On Fedora 23 ... $ openssl ecparam -list_curves secp256k1 : SECG curve over a 256 bit prime field secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field There's a long history surrounding the lack of ECC support in openssl in Fedora, RHEL, and CentOS because of legal issues - see https://bugzilla.redhat.com/show_bug.cgi?id=319901 Some ECC curves are now available, but each additional one requested will be considered individually - there is a tracker bug for this: https://bugzilla.redhat.com/showdependencytree.cgi?id=1019390&hide_resolved=0 This is the failure I'm seeing since https://review.openstack.org/#/c/256069/ was merged nova.tests.unit.test_signature_utils.TestSignatureUtils.test_verify_signature_ECC - Captured traceback: ~~~ Traceback (most recent call last): File "/home/markmc/git/openstack/nova/.tox/py27/lib/python2.7/site-packages/mock/mock.py", line 1305, in patched return func(*args, **keywargs) File "nova/tests/unit/test_signature_utils.py", line 178, in test_verify_signature_ECC default_backend()) File "/home/markmc/git/openstack/nova/.tox/py27/lib/python2.7/site-packages/cryptography/hazmat/primitives/asymmetric/ec.py", line 241, in generate_private_key return backend.generate_elliptic_curve_private_key(curve) File "/home/markmc/git/openstack/nova/.tox/py27/lib/python2.7/site-packages/cryptography/hazmat/backends/multibackend.py", line 247, in generate_elliptic_curve_private_key _Reasons.UNSUPPORTED_ELLIPTIC_CURVE cryptography.exceptions.UnsupportedAlgorithm: This backend does not support this elliptic curve. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1528393/+subscriptions -- Mailing list: https://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 1530179] [NEW] get_subnet_for_dvr() returns wrong gateway mac
Public bug reported: get_subnet_for_dvr should return proper gateway mac address in order for ovs agent to add proper flows for dvr interface on br-int. commit e82b0e108332964c90e9d2cfaf3d334a92127155 added 'fixed_ips' parameter to the handler to filter gateway port of the subnet. However actual filtering was applied improperly which leads to wrong gateway mac being returned: if fixed_ips: filter = fixed_ips[0] else: filter = {'fixed_ips': {'subnet_id': [subnet], 'ip_address': [subnet_info['gateway_ip']]}} internal_gateway_ports = self.plugin.get_ports( context, filters=filter) internal_port = internal_gateway_ports[0] subnet_info['gateway_mac'] = internal_port['mac_address'] get_ports() here actually returns _all_ ports so mac address of a random port is returned as 'gateway_mac'. In most cases it doesn't lead to any noticeable side effects but in some cases it may cause very weird behavior. The case that we faced was: root@node-9:~# ovs-ofctl dump-flows br-int ... cookie=0x971c69a135b8ce1f, duration=23023.412s, table=2, n_packets=1339, n_bytes=131234, idle_age=19050, priority=4,dl_vlan=3556,dl_dst=fa:16:3e:da:53:f1 actions=strip_vlan,mod_dl_src:fa:16:3e:2c:24:86,output:6 cookie=0x971c69a135b8ce1f, duration=31946.414s, table=2, n_packets=25320, n_bytes=2481408, idle_age=1, priority=4,dl_vlan=3556,dl_dst=fa:16:3e:2c:24:86 actions=strip_vlan,mod_dl_src:fa:16:3e:2c:24:86,output:5 ... fa:16:3e:2c:24:86 is mac address of a vm port and it was returned as gateway mac due to the bug. This vm was unreachable from other subnets connected to the same dvr router. However another vm on the same host and the same subnet was ok. It took a while to find out what was wrong :) ** Affects: neutron Importance: Medium Assignee: Oleg Bondarev (obondarev) Status: New ** Tags: l3-dvr-backlog -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1530179 Title: get_subnet_for_dvr() returns wrong gateway mac Status in neutron: New Bug description: get_subnet_for_dvr should return proper gateway mac address in order for ovs agent to add proper flows for dvr interface on br-int. commit e82b0e108332964c90e9d2cfaf3d334a92127155 added 'fixed_ips' parameter to the handler to filter gateway port of the subnet. However actual filtering was applied improperly which leads to wrong gateway mac being returned: if fixed_ips: filter = fixed_ips[0] else: filter = {'fixed_ips': {'subnet_id': [subnet], 'ip_address': [subnet_info['gateway_ip']]}} internal_gateway_ports = self.plugin.get_ports( context, filters=filter) internal_port = internal_gateway_ports[0] subnet_info['gateway_mac'] = internal_port['mac_address'] get_ports() here actually returns _all_ ports so mac address of a random port is returned as 'gateway_mac'. In most cases it doesn't lead to any noticeable side effects but in some cases it may cause very weird behavior. The case that we faced was: root@node-9:~# ovs-ofctl dump-flows br-int ... cookie=0x971c69a135b8ce1f, duration=23023.412s, table=2, n_packets=1339, n_bytes=131234, idle_age=19050, priority=4,dl_vlan=3556,dl_dst=fa:16:3e:da:53:f1 actions=strip_vlan,mod_dl_src:fa:16:3e:2c:24:86,output:6 cookie=0x971c69a135b8ce1f, duration=31946.414s, table=2, n_packets=25320, n_bytes=2481408, idle_age=1, priority=4,dl_vlan=3556,dl_dst=fa:16:3e:2c:24:86 actions=strip_vlan,mod_dl_src:fa:16:3e:2c:24:86,output:5 ... fa:16:3e:2c:24:86 is mac address of a vm port and it was returned as gateway mac due to the bug. This vm was unreachable from other subnets connected to the same dvr router. However another vm on the same host and the same subnet was ok. It took a while to find out what was wrong :) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1530179/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests
Reviewed: https://review.openstack.org/261415 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=aed4d660984adaf70eccce36066d56973939027b Submitter: Jenkins Branch:master commit aed4d660984adaf70eccce36066d56973939027b Author: LiuNanke Date: Fri Dec 25 13:33:35 2015 +0800 Replace assertEqual(None,*) with assertIsNone Replace assertEqual(None, *) with assertIsNone in tests to have more clear messages in case of failure. Closes-Bug: #1280522 Change-Id: I950881a51053d83762c941d813da6bbf9f8578c9 ** 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 Compute (nova). https://bugs.launchpad.net/bugs/1280522 Title: Replace assertEqual(None, *) with assertIsNone in tests Status in Anchor: Fix Released Status in Cinder: Fix Released Status in Glance: Fix Released Status in glance_store: Fix Released Status in heat: Fix Released Status in heat-cfntools: In Progress Status in Heat Translator: In Progress Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: In Progress Status in OpenStack Identity (keystone): Fix Released Status in Manila: Fix Released Status in networking-cisco: In Progress Status in OpenStack Compute (nova): Fix Released Status in os-client-config: Fix Released Status in python-barbicanclient: In Progress Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-congressclient: In Progress Status in python-cueclient: In Progress Status in python-designateclient: In Progress Status in python-glanceclient: Fix Released Status in python-heatclient: In Progress Status in python-ironicclient: Fix Released Status in python-manilaclient: In Progress Status in python-neutronclient: Fix Released Status in python-openstackclient: In Progress Status in python-troveclient: Fix Released Status in Python client library for Zaqar: Fix Released Status in Sahara: Fix Released Status in Solum: In Progress Status in tempest: Fix Released Status in Trove: Fix Released Status in tuskar: Fix Released Status in zaqar: In Progress Bug description: Replace assertEqual(None, *) with assertIsNone in tests to have more clear messages in case of failure. To manage notifications about this bug go to: https://bugs.launchpad.net/anchor/+bug/1280522/+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 1529534] Re: User new log style where Logger.exception() is used by passing an exception object as the first argument.
This is invalid. An exception object should not be passed to log.exception. That logs whatever exception is in scope, so passing in the exception results in it being logged twice. If passing to log.error, six.text_type is recommended. ** Changed in: cinder Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1529534 Title: User new log style where Logger.exception() is used by passing an exception object as the first argument. Status in Ceilometer: New Status in Cinder: Invalid Status in Gnocchi: In Progress Status in Ironic: In Progress Status in Magnum: In Progress Status in Manila: In Progress Status in OpenStack Compute (nova): In Progress Status in python-ceilometerclient: New Status in python-glanceclient: New Status in python-gnocchiclient: In Progress Status in python-keystoneclient: New Status in python-neutronclient: Confirmed Status in python-troveclient: New Status in Sahara: New Status in Trove: New Bug description: Use new log style where Logger.exception() is used by passing an exception object as the first argument[1]. [1]http://docs.openstack.org/developer/oslo.log/usage.html#no-more- implicit-conversion-to-unicode-str To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1529534/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1528382] Re: default theme's warning color is not readable
Reviewed: https://review.openstack.org/260245 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=bffc1a645e23b71d934002ab81ff56fe8c9a43e9 Submitter: Jenkins Branch:master commit bffc1a645e23b71d934002ab81ff56fe8c9a43e9 Author: Diana Whitten Date: Mon Dec 21 16:30:29 2015 -0700 default theme's warning color is not readable It was far too bright to make out with white lettering. Change-Id: Ib3695cc630fb41df4a3bd63506f1ba705bf940a8 Closes-bug: #1528382 ** 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/1528382 Title: default theme's warning color is not readable Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Its far too light: https://www.dropbox.com/s/f6cl12jfdxd4llr/Screenshot%202015-12-21%2016.26.48.png?dl=0 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1528382/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1529534] Re: User new log style where Logger.exception() is used by passing an exception object as the first argument.
Change abandoned by LiuNanke (nanke@easystack.cn) on branch: master Review: https://review.openstack.org/262263 ** Changed in: cinder Status: Invalid => 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/1529534 Title: User new log style where Logger.exception() is used by passing an exception object as the first argument. Status in Ceilometer: New Status in Cinder: In Progress Status in Gnocchi: In Progress Status in Ironic: In Progress Status in Magnum: In Progress Status in Manila: In Progress Status in OpenStack Compute (nova): In Progress Status in python-ceilometerclient: New Status in python-glanceclient: New Status in python-gnocchiclient: In Progress Status in python-keystoneclient: New Status in python-neutronclient: Confirmed Status in python-troveclient: New Status in Sahara: New Status in Trove: New Bug description: Use new log style where Logger.exception() is used by passing an exception object as the first argument[1]. [1]http://docs.openstack.org/developer/oslo.log/usage.html#no-more- implicit-conversion-to-unicode-str To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1529534/+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 1529913] Re: use warning to avoid DeprecationWarning
Reviewed: https://review.openstack.org/262232 Committed: https://git.openstack.org/cgit/openstack/trove/commit/?id=1ee6814457e454dd86d263563d7cadd15dce3113 Submitter: Jenkins Branch:master commit 1ee6814457e454dd86d263563d7cadd15dce3113 Author: LiuNanke Date: Tue Dec 29 22:45:10 2015 +0800 Using LOG.warning replace LOG.warn *Python 3 deprecated the logger.warn method, see: *https://docs.python.org/3/library/logging.html#logging.warning *so we prefer to use warning to avoid DeprecationWarning. Closes-Bug: #1529913 Change-Id: Iae9e13e89bb9566c2482017f631408a95ffe002d ** Changed in: trove Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1529913 Title: use warning to avoid DeprecationWarning Status in Glance: In Progress Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): In Progress Status in Manila: New Status in OpenStack Compute (nova): In Progress Status in Trove: Fix Released Bug description: Python 3 deprecated the logger.warn method, see: https://docs.python.org/3/library/logging.html#logging.warning so we prefer to use warning to avoid DeprecationWarning. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1529913/+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 1530214] [NEW] Tempest failures due to iSCSI DB failure on compute node
Public bug reported: Noticed a couple of these today in the SolidFire CI system. These are initiator side errors in Nova. Excerpt from log is below, but additional logs can also be viewed here: http://54.164.167.86/solidfire-ci-logs/refs-changes-67-244867-12/logs/screen-n-cpu.log.txt 2015-12-30 20:53:50.829 ERROR nova.virt.block_device [req-0f1602ac-0604-4051-8d65-81ede0976dc5 tempest-DeleteServersTestJSON-1052804341 tempest-DeleteServersTestJSON-308638552] [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] Driver failed to attach volume 23049317-f6c2-40b2-9306-0b838848f911 at /dev/vdb 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] Traceback (most recent call last): 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/nova/nova/virt/block_device.py", line 288, in attach 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] device_type=self['device_type'], encryption=encryption) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 1114, in attach_volume 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] self._connect_volume(connection_info, disk_info) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 1064, in _connect_volume 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] vol_driver.connect_volume(connection_info, disk_info) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/nova/nova/virt/libvirt/volume/iscsi.py", line 84, in connect_volume 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] device_info = self.connector.connect_volume(connection_info['data']) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 271, in inner 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] return f(*args, **kwargs) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/os-brick/os_brick/initiator/connector.py", line 763, in connect_volume 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] connection_properties) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/os-brick/os_brick/initiator/connector.py", line 591, in _get_potential_volume_paths 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] if self._connect_to_iscsi_portal(props): 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/os-brick/os_brick/initiator/connector.py", line 1044, in _connect_to_iscsi_portal 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] self._run_iscsiadm(connection_properties, ()) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/os-brick/os_brick/initiator/connector.py", line 948, in _run_iscsiadm 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] delay_on_retry=delay_on_retry) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", line 312, in execute 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] cmd=sanitized_cmd) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] ProcessExecutionError: Unexpected error while running command. 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] Command: sudo nova-rootwrap /etc/nova/rootwrap.conf iscsiadm -m node -T iqn.2010-01.com.solidfire:l74j.uuid-23049317-f6c2-40b2-9306-0b838848f911.374375 -p 10.10.64.3:3260 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] Exit code: 6 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c]
[Yahoo-eng-team] [Bug 1530214] Re: Tempest failures due to iSCSI DB failure on compute node
** Also affects: os-brick 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/1530214 Title: Tempest failures due to iSCSI DB failure on compute node Status in OpenStack Compute (nova): New Status in os-brick: New Bug description: Noticed a couple of these today in the SolidFire CI system. These are initiator side errors in Nova. Excerpt from log is below, but additional logs can also be viewed here: http://54.164.167.86/solidfire-ci-logs/refs-changes-67-244867-12/logs/screen-n-cpu.log.txt 2015-12-30 20:53:50.829 ERROR nova.virt.block_device [req-0f1602ac-0604-4051-8d65-81ede0976dc5 tempest-DeleteServersTestJSON-1052804341 tempest-DeleteServersTestJSON-308638552] [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] Driver failed to attach volume 23049317-f6c2-40b2-9306-0b838848f911 at /dev/vdb 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] Traceback (most recent call last): 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/nova/nova/virt/block_device.py", line 288, in attach 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] device_type=self['device_type'], encryption=encryption) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 1114, in attach_volume 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] self._connect_volume(connection_info, disk_info) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 1064, in _connect_volume 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] vol_driver.connect_volume(connection_info, disk_info) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/nova/nova/virt/libvirt/volume/iscsi.py", line 84, in connect_volume 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] device_info = self.connector.connect_volume(connection_info['data']) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 271, in inner 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] return f(*args, **kwargs) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/os-brick/os_brick/initiator/connector.py", line 763, in connect_volume 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] connection_properties) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/os-brick/os_brick/initiator/connector.py", line 591, in _get_potential_volume_paths 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] if self._connect_to_iscsi_portal(props): 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/os-brick/os_brick/initiator/connector.py", line 1044, in _connect_to_iscsi_portal 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] self._run_iscsiadm(connection_properties, ()) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/os-brick/os_brick/initiator/connector.py", line 948, in _run_iscsiadm 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] delay_on_retry=delay_on_retry) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", line 312, in execute 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] cmd=sanitized_cmd) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] ProcessExecutionError: Unexpected error while running command. 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d15263
[Yahoo-eng-team] [Bug 1530214] Re: Tempest failures due to iSCSI DB failure on compute node
*** This bug is a duplicate of bug 1324670 *** https://bugs.launchpad.net/bugs/1324670 Looks like this is an old one we thought was fixed on the brick side. Removing Nova and marking as a duplicate of the original bug: 1324670 ** No longer affects: nova ** This bug has been marked a duplicate of bug 1324670 'iscsiadm ... -o delete' fails occasionally on bulk deployments -- 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/1530214 Title: Tempest failures due to iSCSI DB failure on compute node Status in os-brick: New Bug description: Noticed a couple of these today in the SolidFire CI system. These are initiator side errors in Nova. Excerpt from log is below, but additional logs can also be viewed here: http://54.164.167.86/solidfire-ci-logs/refs-changes-67-244867-12/logs/screen-n-cpu.log.txt 2015-12-30 20:53:50.829 ERROR nova.virt.block_device [req-0f1602ac-0604-4051-8d65-81ede0976dc5 tempest-DeleteServersTestJSON-1052804341 tempest-DeleteServersTestJSON-308638552] [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] Driver failed to attach volume 23049317-f6c2-40b2-9306-0b838848f911 at /dev/vdb 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] Traceback (most recent call last): 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/nova/nova/virt/block_device.py", line 288, in attach 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] device_type=self['device_type'], encryption=encryption) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 1114, in attach_volume 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] self._connect_volume(connection_info, disk_info) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 1064, in _connect_volume 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] vol_driver.connect_volume(connection_info, disk_info) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/nova/nova/virt/libvirt/volume/iscsi.py", line 84, in connect_volume 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] device_info = self.connector.connect_volume(connection_info['data']) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 271, in inner 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] return f(*args, **kwargs) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/os-brick/os_brick/initiator/connector.py", line 763, in connect_volume 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] connection_properties) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/os-brick/os_brick/initiator/connector.py", line 591, in _get_potential_volume_paths 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] if self._connect_to_iscsi_portal(props): 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/os-brick/os_brick/initiator/connector.py", line 1044, in _connect_to_iscsi_portal 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] self._run_iscsiadm(connection_properties, ()) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/opt/stack/os-brick/os_brick/initiator/connector.py", line 948, in _run_iscsiadm 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] delay_on_retry=delay_on_retry) 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c] File "/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", line 312, in execute 2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: d1526309-a49f-46b3-9a29-7d7ae285be9c]
[Yahoo-eng-team] [Bug 1521360] Re: Add Member action in loadbalancers does not enforce protocol as required field
Reviewed: https://review.openstack.org/252409 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=5d384cb18da4e274e63938916d941f367b564386 Submitter: Jenkins Branch:master commit 5d384cb18da4e274e63938916d941f367b564386 Author: Tatiana Ovchinnikova Date: Wed Dec 2 16:50:53 2015 +0300 Protocol port should be required for LBaaS Add Member Protocol port field should be required for LBaaS Add Member action, no matter what member source is chosen. This patch set also fixes members field's label for the case when there is no available servers. Change-Id: Ib0a00a2b7acdbb0d3dd454e54122ec601889a1fc Closes-Bug: #1521360 ** 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/1521360 Title: Add Member action in loadbalancers does not enforce protocol as required field Status in OpenStack Dashboard (Horizon): Fix Released Bug description: In Project->Networks->Load Balancers: 1. Click on Members tab 2. Click on 'Add Member' button **Make sure there are no instances to be added as members.** Protocol Port is not a required field but if you don't enter the port, it fails with message "Unable to add members" which does not indicate the actual error. Horizon log shows this error: 2015-11-30 21:09:39,964 DEBUG 25947 [neutronclient.client]: RESP:400 {'date': 'Mon, 30 Nov 2015 21:09:39 GMT', 'connection': 'keep-alive', 'content-type': 'application/json; charset=UTF-8', 'content-length': '124', 'x-openstack-request-id': 'req-e140a1b7-72dd-46d1-9033-159d1897988a'} {"NeutronError": {"message": "Invalid input for operation: 'None' is not a integer.", "type": "InvalidInput", "detail": ""}} 2015-11-30 21:09:39,964 DEBUG 25947 [neutronclient.v2_0.client]: Error message: {"NeutronError": {"message": "Invalid input for operation: 'None' is not a integer.", "type": "InvalidInput", "detail": ""}} Neutron Log shows the following error: 2015-11-30 21:09:39,961DEBUG [neutron.api.v2.base] 597 Request body: {u'member': {u'protocol_port': None, u'pool_id': u'b4996970-2d8f-4d9f-b553-a55bf1a159d0', u'address': u'10.2.2.5', u'admin_state_up': True}} 2015-11-30 21:09:39,962 INFO [neutron.api.v2.resource] 95 create failed (client error): Invalid input for operation: 'None' is not a integer. Looks like the underlying problem is that protocol_port is removed as a requirement when there are no instances available to be selected as members. However, user can still choose the other way of entering the member ip address and will run into this problem (protocol_port.required will still be set to False as there are no servers). To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1521360/+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 1530249] [NEW] Use six.moves.reduce instead of builtin reduce
Public bug reported: Builtin function 'reduce' in Python 2 has been moved to standard library module in Python 3 [1]. To make code compatible, we should replace reduce(expr) with six.moves.reduce(expr) [1] http://python3porting.com/stdlib.html#moved-builtins ** Affects: glance Importance: Undecided Assignee: HouMing Wang (houming-wang) Status: In Progress ** Changed in: glance Assignee: (unassigned) => HouMing Wang (houming-wang) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1530249 Title: Use six.moves.reduce instead of builtin reduce Status in Glance: In Progress Bug description: Builtin function 'reduce' in Python 2 has been moved to standard library module in Python 3 [1]. To make code compatible, we should replace reduce(expr) with six.moves.reduce(expr) [1] http://python3porting.com/stdlib.html#moved-builtins To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1530249/+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 1530249] Re: Use six.moves.reduce instead of builtin reduce
** Also affects: cinder Importance: Undecided Status: New ** Changed in: cinder Assignee: (unassigned) => LiuNanke (nanke-liu) ** Changed in: cinder Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1530249 Title: Use six.moves.reduce instead of builtin reduce Status in Cinder: In Progress Status in Glance: In Progress Bug description: Builtin function 'reduce' in Python 2 has been moved to standard library module in Python 3 [1]. To make code compatible, we should replace reduce(expr) with six.moves.reduce(expr) [1] http://python3porting.com/stdlib.html#moved-builtins To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1530249/+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 1530249] Re: Use six.moves.reduce instead of builtin reduce
** Changed in: cinder Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1530249 Title: Use six.moves.reduce instead of builtin reduce Status in Cinder: Invalid Status in Glance: In Progress Bug description: Builtin function 'reduce' in Python 2 has been moved to standard library module in Python 3 [1]. To make code compatible, we should replace reduce(expr) with six.moves.reduce(expr) [1] http://python3porting.com/stdlib.html#moved-builtins To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1530249/+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 1529534] Re: User new log style where Logger.exception() is used by passing an exception object as the first argument.
** No longer affects: manila -- 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/1529534 Title: User new log style where Logger.exception() is used by passing an exception object as the first argument. Status in Ceilometer: New Status in Cinder: In Progress Status in Gnocchi: In Progress Status in Ironic: In Progress Status in Magnum: In Progress Status in OpenStack Compute (nova): In Progress Status in python-ceilometerclient: New Status in python-glanceclient: New Status in python-gnocchiclient: In Progress Status in python-keystoneclient: New Status in python-neutronclient: Confirmed Status in python-troveclient: New Status in Sahara: New Status in Trove: New Bug description: Use new log style where Logger.exception() is used by passing an exception object as the first argument[1]. [1]http://docs.openstack.org/developer/oslo.log/usage.html#no-more- implicit-conversion-to-unicode-str To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1529534/+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 1530249] Re: Use six.moves.reduce instead of builtin reduce
** No longer affects: cinder -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1530249 Title: Use six.moves.reduce instead of builtin reduce Status in Glance: In Progress Bug description: Builtin function 'reduce' in Python 2 has been moved to standard library module in Python 3 [1]. To make code compatible, we should replace reduce(expr) with six.moves.reduce(expr) [1] http://python3porting.com/stdlib.html#moved-builtins To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1530249/+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 1276694] Re: Openstack services should support SIGHUP signal
I think keystone gets this for free since we're using oslo.service (https://github.com/openstack/keystone/blob/master/requirements.txt#L32) for eventlet. for the case of running keystone under httpd, i think most support SIGHUP: https://httpd.apache.org/docs/2.2/en/stopping.html ** Changed in: keystone Status: Confirmed => 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/1276694 Title: Openstack services should support SIGHUP signal Status in Glance: Fix Released Status in heat: Fix Released Status in OpenStack Identity (keystone): Invalid Status in Murano: Confirmed Status in neutron: In Progress Status in OpenStack Compute (nova): Fix Released Status in oslo-incubator: Invalid Status in oslo.config: New Status in oslo.log: New Status in oslo.service: Fix Released Status in Sahara: In Progress Bug description: 1)In order to more effectively manage the unlinked and open (lsof +L1) log files descriptors w/o restarting the services, SIGHUP signal should be accepted by every Openstack service. That would allow, e.g. logrotate jobs to gracefully HUP services after their log files were rotated. The only option we have for now is to force the services restart, quite a poor option from the services continuous accessibility PoV. Note: according to http://en.wikipedia.org/wiki/Unix_signal SIGHUP ... Many daemons will reload their configuration files and reopen their logfiles instead of exiting when receiving this signal. Currently Murano and Glance are out of sync with Oslo SIGHUP support. There is also the following issue exists for some of the services of OS projects with synced SIGHUP support: 2) heat-api-cfn, heat-api, heat-api-cloudwatch, keystone: looks like the synced code is never being executed, thus SIGHUP is not supported for them. Here is a simple test scenario: 2.1) modify /site-packages//openstack/common/service.py def _sighup_supported(): +LOG.warning("SIGHUP is supported: {0}".format(hasattr(signal, 'SIGHUP'))) return hasattr(signal, 'SIGHUP') 2.2) restart service foo-service-name and check logs for "SIGHUP is supported", if service really supports it, the appropriate messages would be present in the logs. 2.3) issue kill -HUP and check logs for "SIGHUP is supported" and "Caught SIGHUP", if service really supports it, the appropriate messages would be present in the logs. Besides that, the service should remain started and its main thread PID should not be changed. e.g. 2.a) heat-engine supports HUPing: #service openstack-heat-engine restart <132>Apr 11 14:03:48 node-3 heat-heat.openstack.common.service WARNING: SIGHUP is supported: True 2.b)But heat-api don't know how to HUP: #service openstack-heat-api restart <134>Apr 11 14:06:22 node-3 heat-heat.api INFO: Starting Heat ReST API on 0.0.0.0:8004 <134>Apr 11 14:06:22 node-3 heat-eventlet.wsgi.server INFO: Starting single process server 2.c) HUPing heat-engine is OK #pid=$(cat /var/run/heat/openstack-heat-engine.pid); kill -HUP $pid && echo $pid 16512 <134>Apr 11 14:12:15 node-3 heat-heat.openstack.common.service INFO: Caught SIGHUP, exiting <132>Apr 11 14:12:15 node-3 heat-heat.openstack.common.service WARNING: SIGHUP is supported: True <134>Apr 11 14:12:15 node-3 heat-heat.openstack.common.rpc.common INFO: Connected to AMQP server on ... service openstack-heat-engine status openstack-heat-engine (pid 16512) is running... 2.d) HUPed heat-api is dead now ;( #kill -HUP $(cat /var/run/heat/openstack-heat-api.pid) (no new logs) # service openstack-heat-api status openstack-heat-api dead but pid file exists 3) nova-cert, nova-novncproxy, nova-objectstore, nova-consoleauth, nova-scheduler - unlike to case 2, after kill -HUP command was issued, there would be a "Caught SIGHUP" message in the logs, BUT the associated service would have got dead anyway. Instead, the service should remain started and its main thread PID should not be changed (similar to the 2.c case). So, looks like there are a lot of things still should be done to ensure POSIX standards abidance in Openstack :-) To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1276694/+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 1530275] [NEW] Live snapshot is corrupted (possibly race condition?)
Public bug reported: We are using nova 2:12.0.0-0ubuntu2~cloud0. Instance disks are stored in qcow2 files on ext4 filesystem. When we live snapshot, 90% of the time the produced image is corrupted; specifically, the image is only a few megabytes (e.g. 30 MB) in size, while the disk size is several GB. Here is the log from a corrupted snapshot: 2015-12-31 01:40:33.304 16805 INFO nova.compute.manager [req-80187ec9-a3e7-4eaf-80d4-1617da40989e 94b1e02c35204ca89bd5aea99ff5ef2b 8341c85ad9ae49408fa25074adba0480 - - -] [instance: f9d52a00-8466-4436-b5b4-f0244d54dfe1] instance snapshotting 2015-12-31 01:40:33.410 16805 INFO nova.virt.libvirt.driver [req-80187ec9-a3e7-4eaf-80d4-1617da40989e 94b1e02c35204ca89bd5aea99ff5ef2b 8341c85ad9ae49408fa25074adba0480 - - -] [instance: f9d52a00-8466-4436-b5b4-f0244d54dfe1] Beginning live snapshot process 2015-12-31 01:40:34.964 16805 INFO nova.virt.libvirt.driver [req-80187ec9-a3e7-4eaf-80d4-1617da40989e 94b1e02c35204ca89bd5aea99ff5ef2b 8341c85ad9ae49408fa25074adba0480 - - -] [instance: f9d52a00-8466-4436-b5b4-f0244d54dfe1] Snapshot extracted, beginning image upload 2015-12-31 01:40:37.029 16805 INFO nova.virt.libvirt.driver [req-80187ec9-a3e7-4eaf-80d4-1617da40989e 94b1e02c35204ca89bd5aea99ff5ef2b 8341c85ad9ae49408fa25074adba0480 - - -] [instance: f9d52a00-8466-4436-b5b4-f0244d54dfe1] Snapshot image upload complete The entire operation completes in a couple of seconds, which is unexpected. While testing, I added some sleep calls to the _live_snapshot function in virt/libvirt/driver.py to debug the problem. A few live snapshot runs were successful, but I'm not confident that it fixed the problem. Anyway, here is the code that I changed: try: # NOTE (rmk): blockRebase cannot be executed on persistent # domains, so we need to temporarily undefine it. # If any part of this block fails, the domain is # re-defined regardless. if guest.has_persistent_configuration(): guest.delete_configuration() # NOTE (rmk): Establish a temporary mirror of our root disk and # issue an abort once we have a complete copy. dev.rebase(disk_delta, copy=True, reuse_ext=True, shallow=True) +time.sleep(10.0) while dev.wait_for_job(): -time.sleep(0.5) +time.sleep(5.0) dev.abort_job() libvirt_utils.chown(disk_delta, os.getuid()) finally: self._host.write_instance_config(xml) if require_quiesce: self.unquiesce(context, instance, image_meta) And the resulting log (which indicates that it is sleeping for not just the initial 10 second call, but even more than that): 2015-12-31 01:42:12.438 21232 INFO nova.compute.manager [req-f3cc4b5b-98b0-4315-b514-de36a07cb8ed 94b1e02c35204ca89bd5aea99ff5ef2b 8341c85ad9ae49408fa25074adba0480 - - -] [instance: f9d52a00-8466-4436-b5b4-f0244d54dfe1] instance snapshotting 2015-12-31 01:42:12.670 21232 INFO nova.virt.libvirt.driver [req-f3cc4b5b-98b0-4315-b514-de36a07cb8ed 94b1e02c35204ca89bd5aea99ff5ef2b 8341c85ad9ae49408fa25074adba0480 - - -] [instance: f9d52a00-8466-4436-b5b4-f0244d54dfe1] Beginning live snapshot process 2015-12-31 01:43:02.411 21232 INFO nova.virt.libvirt.driver [req-f3cc4b5b-98b0-4315-b514-de36a07cb8ed 94b1e02c35204ca89bd5aea99ff5ef2b 8341c85ad9ae49408fa25074adba0480 - - -] [instance: f9d52a00-8466-4436-b5b4-f0244d54dfe1] Snapshot extracted, beginning image upload 2015-12-31 01:44:12.893 21232 INFO nova.virt.libvirt.driver [req-f3cc4b5b-98b0-4315-b514-de36a07cb8ed 94b1e02c35204ca89bd5aea99ff5ef2b 8341c85ad9ae49408fa25074adba0480 - - -] [instance: f9d52a00-8466-4436-b5b4-f0244d54dfe1] Snapshot image upload complete Since sleeping 10 seconds before polling wait_for_job seemed to resolve it, I think there may be a race condition where wait_for_job may be called before the job is fully initialized from the rebase call. I have not had a chance to explore that possibility further though. ** 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/1530275 Title: Live snapshot is corrupted (possibly race condition?) Status in OpenStack Compute (nova): New Bug description: We are using nova 2:12.0.0-0ubuntu2~cloud0. Instance disks are stored in qcow2 files on ext4 filesystem. When we live snapshot, 90% of the time the produced image is corrupted; specifically, the image is only a few megabytes (e.g. 30 MB) in size, while the disk size is several GB. Here is the log from a corrupted snapshot: 2015-12-31 01:40:33.304 16805 INFO nova.compute.manager [req-80187ec9-a3e7-4eaf-80d4-1617da40989e 94b1e02c35204ca89bd5aea99ff5ef2b 8341c85ad9ae49408fa25074adb
[Yahoo-eng-team] [Bug 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()
** Also affects: congress Importance: Undecided Status: New ** Changed in: congress Assignee: (unassigned) => Shuquan Huang (shuquan) -- 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/1268480 Title: assertTrue(isinstance()) in tests should be replace with assertIsInstance() Status in Barbican: In Progress Status in Ceilometer: Fix Released Status in Cinder: In Progress Status in CloudRoast: New Status in congress: In Progress Status in Glance: Fix Released Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: In Progress Status in OpenStack Identity (keystone): Fix Released Status in neutron: Invalid Status in OpenStack Compute (nova): Fix Released Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-glanceclient: Fix Released Status in python-keystoneclient: Fix Released Status in python-novaclient: Fix Released Status in tempest: In Progress Bug description: some of tests use different method of assertTrue(isinstance(A, B)) or assertEqual(type(A), B). The correct way is to use assertIsInstance(A, B) provided by testtools To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1268480/+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