[Yahoo-eng-team] [Bug 1656215] Re: Add qed disk format
** Also affects: python-openstackclient Importance: Undecided Status: New ** Changed in: python-openstackclient Assignee: (unassigned) => yuyafei (yu-yafei) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1656215 Title: Add qed disk format Status in Glance: In Progress Status in Glance Client: New Status in python-openstackclient: New Bug description: QED is an image format (like qcow2, vmdk, etc) that supports backing files and sparse images. http://wiki.qemu.org/Features/QED To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1656215/+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 1656215] [NEW] Add qed disk format
Public bug reported: QED is an image format (like qcow2, vmdk, etc) that supports backing files and sparse images. http://wiki.qemu.org/Features/QED ** Affects: glance Importance: Undecided Assignee: yuyafei (yu-yafei) Status: New ** Affects: python-glanceclient Importance: Undecided Assignee: yuyafei (yu-yafei) Status: New ** Tags: qed ** Changed in: glance Assignee: (unassigned) => yuyafei (yu-yafei) ** Project changed: glance => python-glanceclient ** Also affects: glance Importance: Undecided Status: New ** Changed in: glance Assignee: (unassigned) => yuyafei (yu-yafei) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1656215 Title: Add qed disk format Status in Glance: New Status in Glance Client: New Bug description: QED is an image format (like qcow2, vmdk, etc) that supports backing files and sparse images. http://wiki.qemu.org/Features/QED To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1656215/+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 1596124] Re: Python3 do not use dict.iteritems dict.iterkeys dict.itervalues
** No longer affects: nova -- 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/1596124 Title: Python3 do not use dict.iteritems dict.iterkeys dict.itervalues Status in glance_store: Fix Released Status in python-glanceclient: In Progress Status in python-heatclient: Fix Released Status in OpenStack Object Storage (swift): In Progress Bug description: Python3 do not use dict.iteritemse dict.iterkeys dict.itervalues, which would raise AttributeError: 'dict' object has no attribute 'iterkeys'. To manage notifications about this bug go to: https://bugs.launchpad.net/glance-store/+bug/1596124/+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 1586268] Re: Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq does not work in PY2
** No longer affects: python-troveclient
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1586268
Title:
Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq
does not work in PY2
Status in Ceilometer:
Fix Released
Status in daisycloud-core:
New
Status in heat:
New
Status in OpenStack Dashboard (Horizon):
New
Status in neutron:
In Progress
Status in OpenStack Compute (nova):
In Progress
Status in python-barbicanclient:
New
Status in python-ceilometerclient:
Fix Released
Status in python-cinderclient:
Fix Released
Status in python-congressclient:
Fix Released
Status in python-glanceclient:
In Progress
Status in python-heatclient:
Fix Released
Status in python-keystoneclient:
In Progress
Status in python-manilaclient:
New
Status in python-muranoclient:
Fix Released
Status in python-novaclient:
Fix Released
Status in python-smaugclient:
Fix Released
Status in tempest:
In Progress
Bug description:
Version: master(20160527)
In case cinderclient.tests.unit.test_base.BaseTest.test_eq
self.assertNotEqual does not work.
Class base.Resource defines __eq__() built-in function, but does not define
__ne__() built-in function, so self.assertEqual works but self.assertNotEqual
does not work at all in this test case.
steps:
1 Clone code of python-cinderclient from master.
2 Modify the case of unit test: cinderclient/tests/unit/test_base.py
line50--line62.
def test_eq(self):
# Two resources with same ID: never equal if their info is not equal
r1 = base.Resource(None, {'id': 1, 'name': 'hi'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
self.assertNotEqual(r1, r2)
# Two resources with same ID: equal if their info is equal
r1 = base.Resource(None, {'id': 1, 'name': 'hello'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
# Two resoruces of different types: never equal
r1 = base.Resource(None, {'id': 1})
r2 = volumes.Volume(None, {'id': 1})
self.assertNotEqual(r1, r2)
# Two resources with no ID: equal if their info is equal
r1 = base.Resource(None, {'name': 'joe', 'age': 12})
r2 = base.Resource(None, {'name': 'joe', 'age': 12})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
Modify self.assertEqual(r1, r2) to self.assertNotEqual(r1, r2).
3 Run unit test, and return success.
After that, I make a test:
class Resource(object):
def __init__(self, person):
self.person = person
def __eq__(self, other):
return self.person == other.person
r1 = Resource("test")
r2 = Resource("test")
r3 = Resource("test_r3")
r4 = Resource("test_r4")
print r1 != r2
print r1 == r2
print r3 != r4
print r3 == r4
The result is :
True
True
True
False
Whether r1 is precisely the same to r2 or not, self.assertNotEqual(r1,
r2) return true.So I think self.assertNotEqual doesn't work at all in
python2 and should be modified.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1586268/+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 1586268] Re: Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq does not work in PY2
python-keystoneclient:
https://review.openstack.org/#/c/337435/
** Also affects: python-keystoneclient
Importance: Undecided
Status: New
** Changed in: python-keystoneclient
Assignee: (unassigned) => yuyafei (yu-yafei)
** Changed in: python-keystoneclient
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/1586268
Title:
Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq
does not work in PY2
Status in Ceilometer:
Fix Released
Status in daisycloud-core:
New
Status in heat:
New
Status in OpenStack Dashboard (Horizon):
New
Status in neutron:
In Progress
Status in OpenStack Compute (nova):
In Progress
Status in python-barbicanclient:
New
Status in python-ceilometerclient:
Fix Released
Status in python-cinderclient:
Fix Released
Status in python-congressclient:
Fix Released
Status in python-glanceclient:
In Progress
Status in python-heatclient:
Fix Released
Status in python-keystoneclient:
In Progress
Status in python-manilaclient:
New
Status in python-muranoclient:
Fix Released
Status in python-novaclient:
Fix Released
Status in python-smaugclient:
Fix Released
Status in python-troveclient:
In Progress
Status in tempest:
In Progress
Bug description:
Version: master(20160527)
In case cinderclient.tests.unit.test_base.BaseTest.test_eq
self.assertNotEqual does not work.
Class base.Resource defines __eq__() built-in function, but does not define
__ne__() built-in function, so self.assertEqual works but self.assertNotEqual
does not work at all in this test case.
steps:
1 Clone code of python-cinderclient from master.
2 Modify the case of unit test: cinderclient/tests/unit/test_base.py
line50--line62.
def test_eq(self):
# Two resources with same ID: never equal if their info is not equal
r1 = base.Resource(None, {'id': 1, 'name': 'hi'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
self.assertNotEqual(r1, r2)
# Two resources with same ID: equal if their info is equal
r1 = base.Resource(None, {'id': 1, 'name': 'hello'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
# Two resoruces of different types: never equal
r1 = base.Resource(None, {'id': 1})
r2 = volumes.Volume(None, {'id': 1})
self.assertNotEqual(r1, r2)
# Two resources with no ID: equal if their info is equal
r1 = base.Resource(None, {'name': 'joe', 'age': 12})
r2 = base.Resource(None, {'name': 'joe', 'age': 12})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
Modify self.assertEqual(r1, r2) to self.assertNotEqual(r1, r2).
3 Run unit test, and return success.
After that, I make a test:
class Resource(object):
def __init__(self, person):
self.person = person
def __eq__(self, other):
return self.person == other.person
r1 = Resource("test")
r2 = Resource("test")
r3 = Resource("test_r3")
r4 = Resource("test_r4")
print r1 != r2
print r1 == r2
print r3 != r4
print r3 == r4
The result is :
True
True
True
False
Whether r1 is precisely the same to r2 or not, self.assertNotEqual(r1,
r2) return true.So I think self.assertNotEqual doesn't work at all in
python2 and should be modified.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1586268/+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 1600109] Re: Unit tests should not perform logging, but some tests still use
** Changed in: os-brick Assignee: yuyafei (yu-yafei) => (unassigned) ** No longer affects: os-brick ** No longer affects: python-heatclient ** No longer affects: neutron ** No longer affects: rally ** No longer affects: glance-store ** No longer affects: 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/1600109 Title: Unit tests should not perform logging,but some tests still use Status in Ceilometer: Incomplete Status in Cinder: Incomplete Status in Glance: Incomplete Status in OpenStack Identity (keystone): Won't Fix Status in Magnum: Incomplete Status in OpenStack Compute (nova): Incomplete Status in python-cinderclient: Incomplete Status in python-glanceclient: Incomplete Status in python-keystoneclient: Won't Fix Status in python-neutronclient: Incomplete Status in python-novaclient: Incomplete Status in python-rackclient: Incomplete Status in python-swiftclient: Incomplete Status in rack: Incomplete Status in OpenStack Object Storage (swift): Incomplete Status in OpenStack DBaaS (Trove): Incomplete Bug description: We shuld remove the logging To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1600109/+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 1596124] Re: Python3 do not use dict.iteritems dict.iterkeys dict.itervalues
** No longer affects: cinder -- 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/1596124 Title: Python3 do not use dict.iteritems dict.iterkeys dict.itervalues Status in glance_store: Fix Released Status in OpenStack Compute (nova): In Progress Status in python-glanceclient: In Progress Status in python-heatclient: Fix Released Status in OpenStack Object Storage (swift): In Progress Bug description: Python3 do not use dict.iteritemse dict.iterkeys dict.itervalues, which would raise AttributeError: 'dict' object has no attribute 'iterkeys'. To manage notifications about this bug go to: https://bugs.launchpad.net/glance-store/+bug/1596124/+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 1508442] Re: LOG.warn is deprecated
** Changed in: rally 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/1508442 Title: LOG.warn is deprecated Status in anvil: In Progress Status in Aodh: Fix Released Status in Astara: Fix Released Status in Barbican: Fix Released Status in bilean: Fix Released Status in Ceilometer: Fix Released Status in cloud-init: In Progress Status in cloudkitty: Fix Released Status in congress: Fix Released Status in Designate: Fix Released Status in django-openstack-auth: Fix Released Status in django-openstack-auth-kerberos: In Progress Status in DragonFlow: Fix Released Status in ec2-api: Fix Released Status in Evoque: In Progress Status in Freezer: In Progress Status in gce-api: Fix Released Status in Glance: In Progress Status in Gnocchi: Fix Released Status in heat: Fix Released Status in heat-cfntools: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in KloudBuster: Fix Released Status in kolla: Fix Released Status in Magnum: Fix Released Status in Manila: Fix Released Status in Mistral: In Progress Status in networking-arista: In Progress Status in networking-calico: In Progress Status in networking-cisco: In Progress Status in networking-fujitsu: Fix Released Status in networking-odl: In Progress Status in networking-ofagent: In Progress Status in networking-plumgrid: In Progress Status in networking-powervm: Fix Released Status in networking-vsphere: Fix Released Status in OpenStack Compute (nova): Fix Released Status in nova-powervm: Fix Released Status in nova-solver-scheduler: In Progress Status in octavia: Fix Released Status in openstack-ansible: Fix Released Status in oslo.cache: Fix Released Status in Packstack: Fix Released Status in python-dracclient: Fix Released Status in python-magnumclient: Fix Released Status in RACK: In Progress Status in python-watcherclient: In Progress Status in Rally: Fix Released Status in OpenStack Search (Searchlight): Fix Released Status in senlin: Fix Committed Status in shaker: Fix Released Status in Solum: Fix Released Status in tacker: In Progress Status in tempest: Fix Released Status in tripleo: Fix Released Status in trove-dashboard: Fix Released Status in Vitrage: Fix Committed Status in watcher: Fix Released Status in zaqar: Fix Released Bug description: LOG.warn is deprecated in Python 3 [1] . But it still used in a few places, non-deprecated LOG.warning should be used instead. Note: If we are using logger from oslo.log, warn is still valid [2], but I agree we can switch to LOG.warning. [1]https://docs.python.org/3/library/logging.html#logging.warning [2]https://github.com/openstack/oslo.log/blob/master/oslo_log/log.py#L85 To manage notifications about this bug go to: https://bugs.launchpad.net/anvil/+bug/1508442/+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 1508442] Re: LOG.warn is deprecated
** Also affects: glance Importance: Undecided Status: New ** Changed in: glance Assignee: (unassigned) => yuyafei (yu-yafei) ** No longer affects: glance ** Also affects: rally Importance: Undecided Status: New ** Changed in: rally Assignee: (unassigned) => yuyafei (yu-yafei) -- 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/1508442 Title: LOG.warn is deprecated Status in anvil: In Progress Status in Aodh: Fix Released Status in Astara: Fix Released Status in Barbican: Fix Released Status in bilean: Fix Released Status in Ceilometer: Fix Released Status in cloud-init: In Progress Status in cloudkitty: Fix Released Status in congress: Fix Released Status in Designate: Fix Released Status in django-openstack-auth: Fix Released Status in django-openstack-auth-kerberos: In Progress Status in DragonFlow: Fix Released Status in ec2-api: Fix Released Status in Evoque: In Progress Status in Freezer: In Progress Status in gce-api: Fix Released Status in Gnocchi: Fix Released Status in heat: Fix Released Status in heat-cfntools: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in KloudBuster: Fix Released Status in kolla: Fix Released Status in Magnum: Fix Released Status in Manila: Fix Released Status in Mistral: In Progress Status in networking-arista: In Progress Status in networking-calico: In Progress Status in networking-cisco: In Progress Status in networking-fujitsu: Fix Released Status in networking-odl: In Progress Status in networking-ofagent: In Progress Status in networking-plumgrid: In Progress Status in networking-powervm: Fix Released Status in networking-vsphere: Fix Released Status in OpenStack Compute (nova): Fix Released Status in nova-powervm: Fix Released Status in nova-solver-scheduler: In Progress Status in octavia: Fix Released Status in openstack-ansible: Fix Released Status in oslo.cache: Fix Released Status in Packstack: Fix Released Status in python-dracclient: Fix Released Status in python-magnumclient: Fix Released Status in RACK: In Progress Status in python-watcherclient: In Progress Status in Rally: New Status in OpenStack Search (Searchlight): Fix Released Status in shaker: Fix Released Status in Solum: Fix Released Status in tempest: Fix Released Status in tripleo: Fix Released Status in trove-dashboard: Fix Released Status in watcher: Fix Released Status in zaqar: Fix Released Bug description: LOG.warn is deprecated in Python 3 [1] . But it still used in a few places, non-deprecated LOG.warning should be used instead. Note: If we are using logger from oslo.log, warn is still valid [2], but I agree we can switch to LOG.warning. [1]https://docs.python.org/3/library/logging.html#logging.warning [2]https://github.com/openstack/oslo.log/blob/master/oslo_log/log.py#L85 To manage notifications about this bug go to: https://bugs.launchpad.net/anvil/+bug/1508442/+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
** Also affects: os-brick Importance: Undecided Status: New ** Changed in: os-brick Assignee: (unassigned) => yuyafei (yu-yafei) -- 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 bifrost: Fix Released Status in Blazar: In Progress Status in Cinder: Fix Released Status in congress: Fix Released Status in Designate: Fix Released Status in dox: New Status in Glance: Fix Released Status in glance_store: Fix Released Status in heat: Fix Released Status in heat-cfntools: Fix Released Status in Heat Translator: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in keystoneauth: Fix Released Status in kolla-mesos: Fix Released Status in Manila: Fix Released Status in networking-cisco: Fix Released Status in OpenStack Compute (nova): Fix Released Status in octavia: Fix Released Status in ooi: Fix Released Status in os-brick: New Status in os-client-config: Fix Released Status in python-barbicanclient: Fix Released Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-congressclient: Fix Released Status in python-cueclient: Fix Released Status in python-designateclient: Fix Released Status in python-glanceclient: Fix Released Status in python-heatclient: Fix Released Status in python-ironicclient: Fix Released Status in python-manilaclient: Fix Released Status in python-neutronclient: Fix Released Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Released Status in python-swiftclient: Fix Released Status in python-troveclient: Fix Released Status in Python client library for Zaqar: Fix Released Status in Sahara: Fix Released Status in OpenStack Search (Searchlight): New Status in Solum: Fix Released Status in Stackalytics: Fix Released Status in tempest: Fix Released Status in OpenStack DBaaS (Trove): Fix Released Status in tuskar: Fix Released Status in watcher: Fix Released Status in zaqar: Fix Released Status in designate package in Ubuntu: Fix Released Status in python-tuskarclient package in Ubuntu: Fix Committed 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 1600109] Re: Unit tests should not perform logging, but some tests still use
** Also affects: trove 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/1600109 Title: Unit tests should not perform logging,but some tests still use Status in Ceilometer: New Status in Cinder: New Status in Glance: New Status in glance_store: New Status in OpenStack Identity (keystone): New Status in Magnum: New Status in neutron: New Status in OpenStack Compute (nova): New Status in os-brick: New Status in python-cinderclient: New Status in python-glanceclient: New Status in python-heatclient: New Status in python-keystoneclient: New Status in python-neutronclient: New Status in python-novaclient: New Status in python-rackclient: New Status in python-swiftclient: New Status in rack: New Status in Rally: New Status in OpenStack Object Storage (swift): New Status in tempest: New Status in OpenStack DBaaS (Trove): New Bug description: We shuld remove the logging To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1600109/+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 1600109] Re: Unit tests should not perform logging, but some tests still use
** Also affects: python-heatclient Importance: Undecided Status: New ** Changed in: python-heatclient Assignee: (unassigned) => yuyafei (yu-yafei) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1600109 Title: Unit tests should not perform logging,but some tests still use Status in Ceilometer: New Status in Cinder: New Status in Glance: New Status in glance_store: New Status in OpenStack Identity (keystone): New Status in neutron: New Status in OpenStack Compute (nova): New Status in os-brick: New Status in python-cinderclient: New Status in python-glanceclient: New Status in python-heatclient: New Status in python-novaclient: New Status in python-rackclient: New Status in rack: New Status in Rally: New Status in OpenStack Object Storage (swift): New Status in tempest: New Bug description: We shuld remove the logging To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1600109/+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 1600109] Re: Unit tests should not perform logging, but some tests still use
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Assignee: (unassigned) => yuyafei (yu-yafei) ** Also affects: ceilometer Importance: Undecided Status: New ** Also affects: tempest Importance: Undecided Status: New ** Changed in: tempest Assignee: (unassigned) => yuyafei (yu-yafei) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1600109 Title: Unit tests should not perform logging,but some tests still use Status in Ceilometer: New Status in Cinder: New Status in Glance: New Status in glance_store: New Status in OpenStack Identity (keystone): New Status in neutron: New Status in OpenStack Compute (nova): New Status in os-brick: New Status in python-cinderclient: New Status in python-glanceclient: New Status in python-heatclient: New Status in python-novaclient: New Status in rack: New Status in Rally: New Status in OpenStack Object Storage (swift): New Status in tempest: New Bug description: We shuld remove the logging To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1600109/+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 1600109] Re: Unit tests should not perform logging, but some tests still use
** Also affects: glance-store Importance: Undecided Status: New ** Changed in: glance-store Assignee: (unassigned) => yuyafei (yu-yafei) -- 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/1600109 Title: Unit tests should not perform logging,but some tests still use Status in Ceilometer: New Status in Cinder: New Status in Glance: New Status in glance_store: New Status in OpenStack Identity (keystone): New Status in neutron: New Status in OpenStack Compute (nova): New Status in os-brick: New Status in python-cinderclient: New Status in python-glanceclient: New Status in python-heatclient: New Status in python-novaclient: New Status in Rally: New Status in OpenStack Object Storage (swift): New Status in tempest: New Bug description: We shuld remove the logging To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1600109/+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 1600109] Re: Unit tests should not perform logging, but some tests still use
** Also affects: os-brick Importance: Undecided Status: New ** Changed in: os-brick Assignee: (unassigned) => yuyafei (yu-yafei) ** Also affects: rally Importance: Undecided Status: New ** Changed in: rally Assignee: (unassigned) => yuyafei (yu-yafei) -- 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/1600109 Title: Unit tests should not perform logging,but some tests still use Status in Cinder: New Status in Glance: New Status in glance_store: New Status in neutron: New Status in OpenStack Compute (nova): New Status in os-brick: New Status in python-cinderclient: New Status in python-glanceclient: New Status in python-novaclient: New Status in Rally: New Status in OpenStack Object Storage (swift): New Bug description: We shuld remove the logging To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1600109/+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 1259292] Re: Some tests use assertEqual(observed, expected) , the argument order is wrong
** Also affects: solum Importance: Undecided Status: New ** Changed in: solum Assignee: (unassigned) => yuyafei (yu-yafei) -- 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/1259292 Title: Some tests use assertEqual(observed, expected) , the argument order is wrong Status in Astara: Fix Released Status in Barbican: In Progress Status in Blazar: New Status in Ceilometer: Invalid Status in Cinder: Fix Released Status in congress: Fix Released Status in daisycloud-core: New Status in Designate: Fix Released Status in Freezer: In Progress Status in Glance: Fix Released Status in glance_store: Fix Released Status in Higgins: New Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): Fix Released Status in Magnum: Fix Released Status in Manila: Fix Released Status in Mistral: Fix Released Status in Murano: Fix Released Status in networking-infoblox: New Status in networking-sfc: In Progress Status in OpenStack Compute (nova): Won't Fix Status in os-brick: In Progress Status in python-barbicanclient: New Status in python-ceilometerclient: Invalid Status in python-cinderclient: Fix Released Status in python-designateclient: Fix Committed Status in python-glanceclient: Fix Released Status in python-mistralclient: Fix Released Status in python-solumclient: Fix Released Status in Python client library for Zaqar: Fix Released Status in Rally: New Status in Sahara: Fix Released Status in Solum: New Status in sqlalchemy-migrate: New Status in SWIFT: New Status in tacker: In Progress Status in tempest: New Status in zaqar: Fix Released Bug description: The test cases will produce a confusing error message if the tests ever fail, so this is worth fixing. To manage notifications about this bug go to: https://bugs.launchpad.net/astara/+bug/1259292/+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 1586268] Re: Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq does not work in PY2
** No longer affects: python-cloudkittyclient (Ubuntu)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1586268
Title:
Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq
does not work in PY2
Status in Ceilometer:
New
Status in Cinder:
New
Status in daisycloud-core:
New
Status in Glance:
New
Status in heat:
New
Status in OpenStack Identity (keystone):
New
Status in keystonemiddleware:
New
Status in neutron:
New
Status in OpenStack Compute (nova):
New
Status in python-barbicanclient:
New
Status in python-ceilometerclient:
In Progress
Status in python-cinderclient:
In Progress
Status in python-congressclient:
New
Status in python-glanceclient:
New
Status in python-heatclient:
In Progress
Status in python-keystoneclient:
New
Status in python-manilaclient:
New
Status in python-muranoclient:
New
Status in python-novaclient:
In Progress
Status in python-smaugclient:
New
Status in python-swiftclient:
New
Status in python-troveclient:
New
Status in Rally:
New
Status in OpenStack Object Storage (swift):
New
Status in tempest:
New
Bug description:
Version: master(20160527)
In case cinderclient.tests.unit.test_base.BaseTest.test_eq
self.assertNotEqual does not work.
Class base.Resource defines __eq__() built-in function, but does not define
__ne__() built-in function, so self.assertEqual works but self.assertNotEqual
does not work at all in this test case.
steps:
1 Clone code of python-cinderclient from master.
2 Modify the case of unit test: cinderclient/tests/unit/test_base.py
line50--line62.
def test_eq(self):
# Two resources with same ID: never equal if their info is not equal
r1 = base.Resource(None, {'id': 1, 'name': 'hi'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
self.assertNotEqual(r1, r2)
# Two resources with same ID: equal if their info is equal
r1 = base.Resource(None, {'id': 1, 'name': 'hello'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
# Two resoruces of different types: never equal
r1 = base.Resource(None, {'id': 1})
r2 = volumes.Volume(None, {'id': 1})
self.assertNotEqual(r1, r2)
# Two resources with no ID: equal if their info is equal
r1 = base.Resource(None, {'name': 'joe', 'age': 12})
r2 = base.Resource(None, {'name': 'joe', 'age': 12})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
Modify self.assertEqual(r1, r2) to self.assertNotEqual(r1, r2).
3 Run unit test, and return success.
After that, I make a test:
class Resource(object):
def __init__(self, person):
self.person = person
def __eq__(self, other):
return self.person == other.person
r1 = Resource("test")
r2 = Resource("test")
r3 = Resource("test_r3")
r4 = Resource("test_r4")
print r1 != r2
print r1 == r2
print r3 != r4
print r3 == r4
The result is :
True
True
True
False
Whether r1 is precisely the same to r2 or not, self.assertNotEqual(r1,
r2) return true.So I think self.assertNotEqual doesn't work at all in
python2 and should be modified.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1586268/+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 1586268] Re: Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq does not work in PY2
** Also affects: python-ceilometerclient
Importance: Undecided
Status: New
** Changed in: python-ceilometerclient
Assignee: (unassigned) => yuyafei (yu-yafei)
** Changed in: python-congressclient
Assignee: (unassigned) => yuyafei (yu-yafei)
** Also affects: python-cloudkittyclient (Ubuntu)
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/1586268
Title:
Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq
does not work in PY2
Status in Ceilometer:
New
Status in Cinder:
New
Status in daisycloud-core:
New
Status in Glance:
New
Status in heat:
New
Status in OpenStack Identity (keystone):
New
Status in keystonemiddleware:
New
Status in neutron:
New
Status in OpenStack Compute (nova):
New
Status in python-ceilometerclient:
New
Status in python-cinderclient:
In Progress
Status in python-congressclient:
New
Status in python-glanceclient:
New
Status in python-heatclient:
In Progress
Status in python-keystoneclient:
New
Status in python-manilaclient:
New
Status in python-muranoclient:
New
Status in python-novaclient:
In Progress
Status in python-smaugclient:
New
Status in python-swiftclient:
New
Status in python-troveclient:
New
Status in Rally:
New
Status in OpenStack Object Storage (swift):
New
Status in tempest:
New
Status in python-cloudkittyclient package in Ubuntu:
New
Bug description:
Version: master(20160527)
In case cinderclient.tests.unit.test_base.BaseTest.test_eq
self.assertNotEqual does not work.
Class base.Resource defines __eq__() built-in function, but does not define
__ne__() built-in function, so self.assertEqual works but self.assertNotEqual
does not work at all in this test case.
steps:
1 Clone code of python-cinderclient from master.
2 Modify the case of unit test: cinderclient/tests/unit/test_base.py
line50--line62.
def test_eq(self):
# Two resources with same ID: never equal if their info is not equal
r1 = base.Resource(None, {'id': 1, 'name': 'hi'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
self.assertNotEqual(r1, r2)
# Two resources with same ID: equal if their info is equal
r1 = base.Resource(None, {'id': 1, 'name': 'hello'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
# Two resoruces of different types: never equal
r1 = base.Resource(None, {'id': 1})
r2 = volumes.Volume(None, {'id': 1})
self.assertNotEqual(r1, r2)
# Two resources with no ID: equal if their info is equal
r1 = base.Resource(None, {'name': 'joe', 'age': 12})
r2 = base.Resource(None, {'name': 'joe', 'age': 12})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
Modify self.assertEqual(r1, r2) to self.assertNotEqual(r1, r2).
3 Run unit test, and return success.
After that, I make a test:
class Resource(object):
def __init__(self, person):
self.person = person
def __eq__(self, other):
return self.person == other.person
r1 = Resource("test")
r2 = Resource("test")
r3 = Resource("test_r3")
r4 = Resource("test_r4")
print r1 != r2
print r1 == r2
print r3 != r4
print r3 == r4
The result is :
True
True
True
False
Whether r1 is precisely the same to r2 or not, self.assertNotEqual(r1,
r2) return true.So I think self.assertNotEqual doesn't work at all in
python2 and should be modified.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1586268/+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 1586268] Re: Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq does not work in PY2
** No longer affects: cloudkitty
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1586268
Title:
Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq
does not work in PY2
Status in Ceilometer:
New
Status in Cinder:
New
Status in daisycloud-core:
New
Status in Glance:
New
Status in heat:
New
Status in OpenStack Identity (keystone):
New
Status in keystonemiddleware:
New
Status in neutron:
New
Status in OpenStack Compute (nova):
New
Status in python-ceilometerclient:
New
Status in python-cinderclient:
In Progress
Status in python-congressclient:
New
Status in python-glanceclient:
New
Status in python-heatclient:
New
Status in python-keystoneclient:
New
Status in python-manilaclient:
New
Status in python-muranoclient:
New
Status in python-novaclient:
In Progress
Status in python-smaugclient:
New
Status in python-troveclient:
New
Status in Rally:
New
Status in OpenStack Object Storage (swift):
New
Status in tempest:
New
Status in python-cloudkittyclient package in Ubuntu:
New
Bug description:
Version: master(20160527)
In case cinderclient.tests.unit.test_base.BaseTest.test_eq
self.assertNotEqual does not work.
Class base.Resource defines __eq__() built-in function, but does not define
__ne__() built-in function, so self.assertEqual works but self.assertNotEqual
does not work at all in this test case.
steps:
1 Clone code of python-cinderclient from master.
2 Modify the case of unit test: cinderclient/tests/unit/test_base.py
line50--line62.
def test_eq(self):
# Two resources with same ID: never equal if their info is not equal
r1 = base.Resource(None, {'id': 1, 'name': 'hi'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
self.assertNotEqual(r1, r2)
# Two resources with same ID: equal if their info is equal
r1 = base.Resource(None, {'id': 1, 'name': 'hello'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
# Two resoruces of different types: never equal
r1 = base.Resource(None, {'id': 1})
r2 = volumes.Volume(None, {'id': 1})
self.assertNotEqual(r1, r2)
# Two resources with no ID: equal if their info is equal
r1 = base.Resource(None, {'name': 'joe', 'age': 12})
r2 = base.Resource(None, {'name': 'joe', 'age': 12})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
Modify self.assertEqual(r1, r2) to self.assertNotEqual(r1, r2).
3 Run unit test, and return success.
After that, I make a test:
class Resource(object):
def __init__(self, person):
self.person = person
def __eq__(self, other):
return self.person == other.person
r1 = Resource("test")
r2 = Resource("test")
r3 = Resource("test_r3")
r4 = Resource("test_r4")
print r1 != r2
print r1 == r2
print r3 != r4
print r3 == r4
The result is :
True
True
True
False
Whether r1 is precisely the same to r2 or not, self.assertNotEqual(r1,
r2) return true.So I think self.assertNotEqual doesn't work at all in
python2 and should be modified.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1586268/+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 1586268] Re: Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq does not work in PY2
** Also affects: cloudkitty
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/1586268
Title:
Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq
does not work in PY2
Status in Ceilometer:
New
Status in daisycloud-core:
New
Status in Glance:
New
Status in heat:
New
Status in OpenStack Identity (keystone):
New
Status in keystonemiddleware:
New
Status in neutron:
New
Status in OpenStack Compute (nova):
New
Status in python-ceilometerclient:
New
Status in python-cinderclient:
In Progress
Status in python-congressclient:
New
Status in python-glanceclient:
New
Status in python-heatclient:
New
Status in python-keystoneclient:
New
Status in python-manilaclient:
New
Status in python-muranoclient:
New
Status in python-novaclient:
In Progress
Status in python-smaugclient:
New
Status in python-troveclient:
New
Status in Rally:
New
Status in OpenStack Object Storage (swift):
New
Status in tempest:
New
Bug description:
Version: master(20160527)
In case cinderclient.tests.unit.test_base.BaseTest.test_eq
self.assertNotEqual does not work.
Class base.Resource defines __eq__() built-in function, but does not define
__ne__() built-in function, so self.assertEqual works but self.assertNotEqual
does not work at all in this test case.
steps:
1 Clone code of python-cinderclient from master.
2 Modify the case of unit test: cinderclient/tests/unit/test_base.py
line50--line62.
def test_eq(self):
# Two resources with same ID: never equal if their info is not equal
r1 = base.Resource(None, {'id': 1, 'name': 'hi'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
self.assertNotEqual(r1, r2)
# Two resources with same ID: equal if their info is equal
r1 = base.Resource(None, {'id': 1, 'name': 'hello'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
# Two resoruces of different types: never equal
r1 = base.Resource(None, {'id': 1})
r2 = volumes.Volume(None, {'id': 1})
self.assertNotEqual(r1, r2)
# Two resources with no ID: equal if their info is equal
r1 = base.Resource(None, {'name': 'joe', 'age': 12})
r2 = base.Resource(None, {'name': 'joe', 'age': 12})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
Modify self.assertEqual(r1, r2) to self.assertNotEqual(r1, r2).
3 Run unit test, and return success.
After that, I make a test:
class Resource(object):
def __init__(self, person):
self.person = person
def __eq__(self, other):
return self.person == other.person
r1 = Resource("test")
r2 = Resource("test")
r3 = Resource("test_r3")
r4 = Resource("test_r4")
print r1 != r2
print r1 == r2
print r3 != r4
print r3 == r4
The result is :
True
True
True
False
Whether r1 is precisely the same to r2 or not, self.assertNotEqual(r1,
r2) return true.So I think self.assertNotEqual doesn't work at all in
python2 and should be modified.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1586268/+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 1586268] Re: Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq does not work in PY2
** Also affects: python-smaugclient
Importance: Undecided
Status: New
** Changed in: python-smaugclient
Assignee: (unassigned) => yuyafei (yu-yafei)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1586268
Title:
Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq
does not work in PY2
Status in Ceilometer:
New
Status in daisycloud-core:
New
Status in Glance:
New
Status in heat:
New
Status in OpenStack Identity (keystone):
New
Status in keystonemiddleware:
New
Status in neutron:
New
Status in OpenStack Compute (nova):
New
Status in python-ceilometerclient:
New
Status in python-cinderclient:
In Progress
Status in python-congressclient:
New
Status in python-glanceclient:
New
Status in python-heatclient:
New
Status in python-keystoneclient:
New
Status in python-manilaclient:
New
Status in python-muranoclient:
New
Status in python-novaclient:
In Progress
Status in python-smaugclient:
New
Status in python-troveclient:
New
Status in Rally:
New
Status in OpenStack Object Storage (swift):
New
Status in tempest:
New
Bug description:
Version: master(20160527)
In case cinderclient.tests.unit.test_base.BaseTest.test_eq
self.assertNotEqual does not work.
Class base.Resource defines __eq__() built-in function, but does not define
__ne__() built-in function, so self.assertEqual works but self.assertNotEqual
does not work at all in this test case.
steps:
1 Clone code of python-cinderclient from master.
2 Modify the case of unit test: cinderclient/tests/unit/test_base.py
line50--line62.
def test_eq(self):
# Two resources with same ID: never equal if their info is not equal
r1 = base.Resource(None, {'id': 1, 'name': 'hi'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
self.assertNotEqual(r1, r2)
# Two resources with same ID: equal if their info is equal
r1 = base.Resource(None, {'id': 1, 'name': 'hello'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
# Two resoruces of different types: never equal
r1 = base.Resource(None, {'id': 1})
r2 = volumes.Volume(None, {'id': 1})
self.assertNotEqual(r1, r2)
# Two resources with no ID: equal if their info is equal
r1 = base.Resource(None, {'name': 'joe', 'age': 12})
r2 = base.Resource(None, {'name': 'joe', 'age': 12})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
Modify self.assertEqual(r1, r2) to self.assertNotEqual(r1, r2).
3 Run unit test, and return success.
After that, I make a test:
class Resource(object):
def __init__(self, person):
self.person = person
def __eq__(self, other):
return self.person == other.person
r1 = Resource("test")
r2 = Resource("test")
r3 = Resource("test_r3")
r4 = Resource("test_r4")
print r1 != r2
print r1 == r2
print r3 != r4
print r3 == r4
The result is :
True
True
True
False
Whether r1 is precisely the same to r2 or not, self.assertNotEqual(r1,
r2) return true.So I think self.assertNotEqual doesn't work at all in
python2 and should be modified.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1586268/+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 1586268] Re: Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq does not work in PY2
** Also affects: python-congressclient
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/1586268
Title:
Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq
does not work in PY2
Status in Ceilometer:
New
Status in daisycloud-core:
New
Status in Glance:
New
Status in heat:
New
Status in OpenStack Identity (keystone):
New
Status in keystonemiddleware:
New
Status in neutron:
New
Status in OpenStack Compute (nova):
New
Status in python-ceilometerclient:
New
Status in python-cinderclient:
In Progress
Status in python-congressclient:
New
Status in python-glanceclient:
New
Status in python-heatclient:
New
Status in python-keystoneclient:
New
Status in python-manilaclient:
New
Status in python-muranoclient:
New
Status in python-novaclient:
In Progress
Status in python-smaugclient:
New
Status in python-troveclient:
New
Status in Rally:
New
Status in OpenStack Object Storage (swift):
New
Status in tempest:
New
Bug description:
Version: master(20160527)
In case cinderclient.tests.unit.test_base.BaseTest.test_eq
self.assertNotEqual does not work.
Class base.Resource defines __eq__() built-in function, but does not define
__ne__() built-in function, so self.assertEqual works but self.assertNotEqual
does not work at all in this test case.
steps:
1 Clone code of python-cinderclient from master.
2 Modify the case of unit test: cinderclient/tests/unit/test_base.py
line50--line62.
def test_eq(self):
# Two resources with same ID: never equal if their info is not equal
r1 = base.Resource(None, {'id': 1, 'name': 'hi'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
self.assertNotEqual(r1, r2)
# Two resources with same ID: equal if their info is equal
r1 = base.Resource(None, {'id': 1, 'name': 'hello'})
r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
# Two resoruces of different types: never equal
r1 = base.Resource(None, {'id': 1})
r2 = volumes.Volume(None, {'id': 1})
self.assertNotEqual(r1, r2)
# Two resources with no ID: equal if their info is equal
r1 = base.Resource(None, {'name': 'joe', 'age': 12})
r2 = base.Resource(None, {'name': 'joe', 'age': 12})
# self.assertEqual(r1, r2)
self.assertNotEqual(r1, r2)
Modify self.assertEqual(r1, r2) to self.assertNotEqual(r1, r2).
3 Run unit test, and return success.
After that, I make a test:
class Resource(object):
def __init__(self, person):
self.person = person
def __eq__(self, other):
return self.person == other.person
r1 = Resource("test")
r2 = Resource("test")
r3 = Resource("test_r3")
r4 = Resource("test_r4")
print r1 != r2
print r1 == r2
print r3 != r4
print r3 == r4
The result is :
True
True
True
False
Whether r1 is precisely the same to r2 or not, self.assertNotEqual(r1,
r2) return true.So I think self.assertNotEqual doesn't work at all in
python2 and should be modified.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1586268/+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 1596124] [NEW] Python3 do not use dict.iteritems dict.iterkeys dict.itervalues
Public bug reported:
Python3 do not use dict.iteritemse dict.iterkeys dict.itervalues, which
would raise AttributeError: 'dict' object has no attribute 'iterkeys'.
** Affects: cinder
Importance: Undecided
Assignee: yuyafei (yu-yafei)
Status: New
** Affects: glance-store
Importance: Undecided
Assignee: yuyafei (yu-yafei)
Status: In Progress
** Affects: nova
Importance: Undecided
Assignee: yuyafei (yu-yafei)
Status: New
** Affects: python-glanceclient
Importance: Undecided
Assignee: yuyafei (yu-yafei)
Status: New
** Affects: python-heatclient
Importance: Undecided
Assignee: yuyafei (yu-yafei)
Status: New
** Changed in: glance-store
Assignee: (unassigned) => yuyafei (yu-yafei)
** Also affects: python-glanceclient
Importance: Undecided
Status: New
** Changed in: python-glanceclient
Assignee: (unassigned) => yuyafei (yu-yafei)
** Also affects: python-heatclient
Importance: Undecided
Status: New
** Changed in: python-heatclient
Assignee: (unassigned) => yuyafei (yu-yafei)
** Also affects: cinder
Importance: Undecided
Status: New
** Changed in: cinder
Assignee: (unassigned) => yuyafei (yu-yafei)
** Also affects: nova
Importance: Undecided
Status: New
** Changed in: nova
Assignee: (unassigned) => yuyafei (yu-yafei)
--
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/1596124
Title:
Python3 do not use dict.iteritems dict.iterkeys dict.itervalues
Status in Cinder:
New
Status in glance_store:
In Progress
Status in OpenStack Compute (nova):
New
Status in python-glanceclient:
New
Status in python-heatclient:
New
Bug description:
Python3 do not use dict.iteritemse dict.iterkeys dict.itervalues,
which would raise AttributeError: 'dict' object has no attribute
'iterkeys'.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1596124/+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 1595830] [NEW] StandardError raises NameError in Python3
Public bug reported: It raises NameError: name 'StandardError' is not defined in Python3. class TimeoutError(StandardError): pass Traceback (most recent call last): File "Z:/test_py3.py", line 1, in class TimeoutError(StandardError): NameError: name 'StandardError' is not defined ** Affects: nova Importance: Undecided Assignee: Bin Zhou (binzhou) Status: New ** Changed in: nova Assignee: (unassigned) => Bin Zhou (binzhou) -- 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/1595830 Title: StandardError raises NameError in Python3 Status in OpenStack Compute (nova): New Bug description: It raises NameError: name 'StandardError' is not defined in Python3. class TimeoutError(StandardError): pass Traceback (most recent call last): File "Z:/test_py3.py", line 1, in class TimeoutError(StandardError): NameError: name 'StandardError' is not defined To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1595830/+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 1583419] Re: Make dict.keys() PY3 compatible
** Also affects: rally
Importance: Undecided
Status: New
** Changed in: rally
Assignee: (unassigned) => yuyafei (yu-yafei)
--
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/1583419
Title:
Make dict.keys() PY3 compatible
Status in Cinder:
In Progress
Status in neutron:
New
Status in OpenStack Compute (nova):
New
Status in python-cinderclient:
Fix Released
Status in python-manilaclient:
In Progress
Status in python-troveclient:
In Progress
Status in Rally:
New
Bug description:
In PY3, dict.keys() will return a view of list but not a list anymore, i.e.
$ python3.4
Python 3.4.3 (default, Mar 31 2016, 20:42:37)
>>> body={"11":"22"}
>>> body[body.keys()[0]]
Traceback (most recent call last):
File "", line 1, in
TypeError: 'dict_keys' object does not support indexing
so for py3 compatible we should change it as follows:
>>> body[list(body.keys())[0]]
'22'
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1583419/+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 1592376] Re: Cinder driver the function add calculate size_gb need improve
** Project changed: glance => glance-store ** Changed in: glance-store Importance: Undecided => Low ** Changed in: glance-store Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1592376 Title: Cinder driver the function add calculate size_gb need improve Status in glance_store: Confirmed Bug description: In the line https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/cinder.py#L436, Its intent is to get ceiling of size_gb. we can use python math module math.ceil() function. This can improve the code readability. So i suggest improve it. To manage notifications about this bug go to: https://bugs.launchpad.net/glance-store/+bug/1592376/+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 1259292] Re: Some tests use assertEqual(observed, expected) , the argument order is wrong
** Also affects: glance-store Importance: Undecided Status: New ** Changed in: glance-store Assignee: (unassigned) => yuyafei (yu-yafei) -- 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/1259292 Title: Some tests use assertEqual(observed, expected) , the argument order is wrong Status in Barbican: In Progress Status in Ceilometer: Invalid Status in Cinder: Fix Released Status in congress: Fix Released Status in Designate: Fix Released Status in Glance: Fix Released Status in glance_store: New Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): Fix Released Status in Magnum: Fix Released Status in Manila: Fix Released Status in Mistral: Fix Released Status in Murano: Fix Released Status in OpenStack Compute (nova): Won't Fix Status in os-brick: In Progress Status in python-ceilometerclient: Invalid Status in python-cinderclient: Fix Released Status in python-designateclient: Fix Committed Status in python-glanceclient: New Status in python-mistralclient: Fix Released Status in python-solumclient: Fix Released Status in Python client library for Zaqar: Fix Released Status in Sahara: Fix Released Status in zaqar: Fix Released Bug description: The test cases will produce a confusing error message if the tests ever fail, so this is worth fixing. To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1259292/+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 1259292] Re: Some tests use assertEqual(observed, expected) , the argument order is wrong
** 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/1259292 Title: Some tests use assertEqual(observed, expected) , the argument order is wrong Status in Barbican: In Progress Status in Ceilometer: Invalid Status in Cinder: Fix Released Status in congress: Fix Released Status in Designate: Fix Released Status in Glance: Fix Released Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): Fix Released Status in Magnum: Fix Released Status in Manila: Fix Released Status in Mistral: Fix Released Status in Murano: Fix Released Status in OpenStack Compute (nova): Won't Fix Status in os-brick: New Status in python-ceilometerclient: Invalid Status in python-cinderclient: Fix Released Status in python-designateclient: Fix Committed Status in python-glanceclient: New Status in python-mistralclient: Fix Released Status in python-solumclient: Fix Released Status in Python client library for Zaqar: Fix Released Status in Sahara: Fix Released Status in zaqar: Fix Released Bug description: The test cases will produce a confusing error message if the tests ever fail, so this is worth fixing. To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1259292/+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 1589916] Re: "glance location-add" failed when url is "cinder：//volume-id"
Thank you, wangxiyuan, Kairat.
That openstack is not exist and my new openstack has no this error.
** Changed in: glance
Status: New => 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/1589916
Title:
"glance location-add" failed when url is "cinder：//volume-id"
Status in Glance:
Invalid
Bug description:
The version is mitaka.
Glance Configuration:
show_image_direct_url=True
show_multiple_locations=True.
Steps:
1. Upload a image (cirros-0.3.1-x86_64-disk.img,
f71dff58-36ca-46ea-8258-0f3c9a4cd747);
2. Create a volume(id:123fb906-bed5-4b55-8a82-1f2e6bed424b) from the
image(backend is fujitsu, others same);
3. Add a location to the image(url:http), success;
#glance location-add --url
http://10.43.176.8/images/cirros-0.3.1-x86_64-disk.img
f71dff58-36ca-46ea-8258-0f3c9a4cd747
4. Add a location to the image(url:cinder//volume-id) failed;
#glance location-add --url cinder://123fb906-bed5-4b55-8a82-1f2e6bed424b
f71dff58-36ca-46ea-8258-0f3c9a4cd747
400 Bad Request
Invalid location
(HTTP 400)
The glance-api log is:
2016-06-08 01:38:04.265 DEBUG eventlet.wsgi.server [-] (30577) accepted
('10.43.203.135', 58926) from (pid=30577) server
/usr/lib/python2.7/site-packages/eventlet/wsgi.py:868
2016-06-08 01:38:04.267 DEBUG glance.api.middleware.version_negotiation [-]
Determining version of request: GET /versions Accept: */* from (pid=30577)
process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:46
2016-06-08 01:38:04.269 INFO eventlet.wsgi.server [-] 10.43.203.135 - -
[08/Jun/2016 01:38:04] "GET /versions HTTP/1.1" 200 793 0.001778
2016-06-08 01:38:04.373 DEBUG eventlet.wsgi.server [-] (30577) accepted
('10.43.203.135', 58929) from (pid=30577) server
/usr/lib/python2.7/site-packages/eventlet/wsgi.py:868
2016-06-08 01:38:04.374 DEBUG glance.api.middleware.version_negotiation [-]
Determining version of request: PATCH
/v2/images/f71dff58-36ca-46ea-8258-0f3c9a4cd747 Accept: */* from (pid=30577)
process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:46
2016-06-08 01:38:04.375 DEBUG glance.api.middleware.version_negotiation [-]
Using url versioning from (pid=30577) process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:58
2016-06-08 01:38:04.375 DEBUG glance.api.middleware.version_negotiation [-]
Matched version: v2 from (pid=30577) process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:70
2016-06-08 01:38:04.376 DEBUG glance.api.middleware.version_negotiation [-]
new path /v2/images/f71dff58-36ca-46ea-8258-0f3c9a4cd747 from (pid=30577)
process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:71
2016-06-08 01:38:04.604 INFO eventlet.wsgi.server
[req-fe0ec689-75f0-4f11-b7ff-692ec84c3a2d 346ce385360c43588f48349ed8f4159e
97330b92c2144c0ea9b8826038d3abe3] 10.43.203.135 - - [08/Jun/2016 01:38:04]
"PATCH /v2/images/f71dff58-36ca-46ea-8258-0f3c9a4cd747 HTTP/1.1" 400 254
0.229389
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1589916/+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 1591971] [NEW] Glance task creates failed when setting word_dir local
Public bug reported:
The version is mitaka.
The glance-api.conf setting is:
[task]
work_dir = /home/work/
[taskflow_executor]
conversion_format = raw
Then run the cli:
glance task-create --type import --input
'{"import_from":"http://10.43.177.17/cirros-0.3.2-x86_64-disk.img","import_from_format":
"","image_properties":{"disk_format":"qcow2","container_format":"bare","name":"test1"}}'
The log is :
2016-06-14 04:08:29.032 DEBUG oslo_concurrency.processutils [-] CMD "qemu-img
info --output=json file:///home/work/90ff2129-0079-487e-a7ec-79ef23bd1c0d"
returned: 1 in 0.025s from (pid=5460) execute
/usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py:374
2016-06-14 04:08:29.033 DEBUG oslo_concurrency.processutils [-] None
command: u'qemu-img info --output=json
file:///home/work/90ff2129-0079-487e-a7ec-79ef23bd1c0d'
exit code: 1
stdout: u''
stderr: u"qemu-img: Could not open
'file:///home/work/90ff2129-0079-487e-a7ec-79ef23bd1c0d': Could not open
'file:///home/work/90ff2129-0079-487e-a7ec-79ef23bd1c0d': No such file or
directory\n" from (pid=5460) execute
/usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py:413
2016-06-14 04:08:29.034 DEBUG oslo_concurrency.processutils [-] u'qemu-img info
--output=json file:///home/work/90ff2129-0079-487e-a7ec-79ef23bd1c0d' failed.
Not Retrying. from (pid=5460) execute
/usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py:422
Command: qemu-img info --output=json
file:///home/work/90ff2129-0079-487e-a7ec-79ef23bd1c0d
Exit code: 1
Stdout: u''
Stderr: u"qemu-img: Could not open
'file:///home/work/90ff2129-0079-487e-a7ec-79ef23bd1c0d': Could not open
'file:///home/work/90ff2129-0079-487e-a7ec-79ef23bd1c0d': No such file or
directory\n"
2016-06-14 04:08:29.072 WARNING glance.async.taskflow_executor [-] Task
'import-ImportToFS-42684807-86db-4ff5-a4a9-abf3b1998b63'
(5ff9cf63-f257-48d2-9cc9-cfeffd905854) transitioned into state 'FAILURE' from
state 'RUNNING'
4 predecessors (most recent first):
Flow 'import'
|__Atom 'import-CreateImage-42684807-86db-4ff5-a4a9-abf3b1998b63'
{'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {}, 'provides':
'90ff2129-0079-487e-a7ec-79ef23bd1c0d'}
|__Atom 'import_retry' {'intention': 'EXECUTE', 'state': 'SUCCESS',
'requires': {}, 'provides': [(None, {})]}
|__Flow 'import'
2016-06-14 04:08:29.072 TRACE glance.async.taskflow_executor Traceback (most
recent call last):
2016-06-14 04:08:29.072 TRACE glance.async.taskflow_executor File
"/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/executor.py",
line 82, in _execute_task
2016-06-14 04:08:29.072 TRACE glance.async.taskflow_executor result =
task.execute(**arguments)
2016-06-14 04:08:29.072 TRACE glance.async.taskflow_executor File
"/opt/stack/glance/glance/async/flows/base_import.py", line 175, in execute
2016-06-14 04:08:29.072 TRACE glance.async.taskflow_executor metadata =
json.loads(stdout)
2016-06-14 04:08:29.072 TRACE glance.async.taskflow_executor File
"/usr/lib64/python2.7/json/__init__.py", line 338, in loads
2016-06-14 04:08:29.072 TRACE glance.async.taskflow_executor return
_default_decoder.decode(s)
2016-06-14 04:08:29.072 TRACE glance.async.taskflow_executor File
"/usr/lib64/python2.7/json/decoder.py", line 365, in decode
2016-06-14 04:08:29.072 TRACE glance.async.taskflow_executor obj, end =
self.raw_decode(s, idx=_w(s, 0).end())
2016-06-14 04:08:29.072 TRACE glance.async.taskflow_executor File
"/usr/lib64/python2.7/json/decoder.py", line 383, in raw_decode
2016-06-14 04:08:29.072 TRACE glance.async.taskflow_executor raise
ValueError("No JSON object could be decoded")
2016-06-14 04:08:29.072 TRACE glance.async.taskflow_executor ValueError: No
JSON object could be decoded
** Affects: glance
Importance: Undecided
Assignee: yuyafei (yu-yafei)
Status: New
** Changed in: glance
Assignee: (unassigned) => yuyafei (yu-yafei)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1591971
Title:
Glance task creates failed when setting word_dir local
Status in Glance:
New
Bug description:
The version is mitaka.
The glance-api.conf setting is:
[task]
work_dir = /home/work/
[taskflow_executor]
conversion_format = raw
Then run the cli:
glance task-create --type import --input
'{"import_from":"http://10.
[Yahoo-eng-team] [Bug 1589916] [NEW] "glance location-add" failed when url is "cinder：//volume-id"
Public bug reported:
The version is mitaka.
Glance Configuration:
show_image_direct_url=True
show_multiple_locations=True.
Steps:
1. Upload a image (cirros-0.3.1-x86_64-disk.img,
f71dff58-36ca-46ea-8258-0f3c9a4cd747);
2. Create a volume(id:123fb906-bed5-4b55-8a82-1f2e6bed424b) from the
image(backend is fujitsu, others same);
3. Add a location to the image(url:http), success;
#glance location-add --url
http://10.43.176.8/images/cirros-0.3.1-x86_64-disk.img
f71dff58-36ca-46ea-8258-0f3c9a4cd747
4. Add a location to the image(url:cinder//volume-id) failed;
#glance location-add --url cinder://123fb906-bed5-4b55-8a82-1f2e6bed424b
f71dff58-36ca-46ea-8258-0f3c9a4cd747
400 Bad Request
Invalid location
(HTTP 400)
The glance-api log is:
2016-06-08 01:38:04.265 DEBUG eventlet.wsgi.server [-] (30577) accepted
('10.43.203.135', 58926) from (pid=30577) server
/usr/lib/python2.7/site-packages/eventlet/wsgi.py:868
2016-06-08 01:38:04.267 DEBUG glance.api.middleware.version_negotiation [-]
Determining version of request: GET /versions Accept: */* from (pid=30577)
process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:46
2016-06-08 01:38:04.269 INFO eventlet.wsgi.server [-] 10.43.203.135 - -
[08/Jun/2016 01:38:04] "GET /versions HTTP/1.1" 200 793 0.001778
2016-06-08 01:38:04.373 DEBUG eventlet.wsgi.server [-] (30577) accepted
('10.43.203.135', 58929) from (pid=30577) server
/usr/lib/python2.7/site-packages/eventlet/wsgi.py:868
2016-06-08 01:38:04.374 DEBUG glance.api.middleware.version_negotiation [-]
Determining version of request: PATCH
/v2/images/f71dff58-36ca-46ea-8258-0f3c9a4cd747 Accept: */* from (pid=30577)
process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:46
2016-06-08 01:38:04.375 DEBUG glance.api.middleware.version_negotiation [-]
Using url versioning from (pid=30577) process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:58
2016-06-08 01:38:04.375 DEBUG glance.api.middleware.version_negotiation [-]
Matched version: v2 from (pid=30577) process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:70
2016-06-08 01:38:04.376 DEBUG glance.api.middleware.version_negotiation [-] new
path /v2/images/f71dff58-36ca-46ea-8258-0f3c9a4cd747 from (pid=30577)
process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:71
2016-06-08 01:38:04.604 INFO eventlet.wsgi.server
[req-fe0ec689-75f0-4f11-b7ff-692ec84c3a2d 346ce385360c43588f48349ed8f4159e
97330b92c2144c0ea9b8826038d3abe3] 10.43.203.135 - - [08/Jun/2016 01:38:04]
"PATCH /v2/images/f71dff58-36ca-46ea-8258-0f3c9a4cd747 HTTP/1.1" 400 254
0.229389
** Affects: glance
Importance: Undecided
Status: New
** Summary changed:
- "glance location-add" failed when url is cinder
+ "glance location-add" failed when url is "cinder：//volume-id"
** Description changed:
The version is mitaka.
Glance Configuration:
show_image_direct_url=True
show_multiple_locations=True.
Steps:
1. Upload a image (cirros-0.3.1-x86_64-disk.img,
f71dff58-36ca-46ea-8258-0f3c9a4cd747);
2. Create a volume(id:123fb906-bed5-4b55-8a82-1f2e6bed424b) from the
image(backend is fujitsu, others same);
3. Add a location to the image(url:http), success;
#glance location-add --url
http://10.43.176.8/images/cirros-0.3.1-x86_64-disk.img
f71dff58-36ca-46ea-8258-0f3c9a4cd747
- 4. Add a location to the image(url:cinder) failed;
+ 4. Add a location to the image(url:cinder//volume-id) failed;
#glance location-add --url cinder://123fb906-bed5-4b55-8a82-1f2e6bed424b
f71dff58-36ca-46ea-8258-0f3c9a4cd747
400 Bad Request
Invalid location
(HTTP 400)
The glance-api log is:
2016-06-08 01:38:04.265 DEBUG eventlet.wsgi.server [-] (30577) accepted
('10.43.203.135', 58926) from (pid=30577) server
/usr/lib/python2.7/site-packages/eventlet/wsgi.py:868
2016-06-08 01:38:04.267 DEBUG glance.api.middleware.version_negotiation [-]
Determining version of request: GET /versions Accept: */* from (pid=30577)
process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:46
2016-06-08 01:38:04.269 INFO eventlet.wsgi.server [-] 10.43.203.135 - -
[08/Jun/2016 01:38:04] "GET /versions HTTP/1.1" 200 793 0.001778
2016-06-08 01:38:04.373 DEBUG eventlet.wsgi.server [-] (30577) accepted
('10.43.203.135', 58929) from (pid=30577) server
/usr/lib/python2.7/site-packages/eventlet/wsgi.py:868
2016-06-08 01:38:04.374 DEBUG glance.api.middleware.version_negotiation [-]
Determining version of request: PATCH
/v2/images/f71dff58-36ca-46ea-8258-0f3c9a4cd747 Accept: */* from (pid=30577)
process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:46
2016-06-08 01:38:04.375 DEBUG glance.api.middleware.version_negotiation [-]
Using url versioning from (pid=30577) process_request
/opt/stack/glance/glance/api/middleware/version_negotiation.py:58
2016-06-08 01:38:04.375 DEBUG glance.api.middleware.version_negotiatio
[Yahoo-eng-team] [Bug 1586586] [NEW] Unit test fails because InvocationError
Public bug reported: I clone the code of glance from github and check out to version mitaka, then run unit test several times using "tox -e py27 --", each end with "InvocationError": Ran 2999 (+2218) tests in 781.701s (+2.504s) FAILED (id=5, failures=264 (+256), skips=13) error: testr failed (1) ERROR: InvocationError: '/home/yu/openstack/glance/.tox/py27/bin/lockutils-wrapper python setup.py testr --slowest --testr-args=' _ summary __ ERROR: py27: commands failed Is this a bug? ** 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/1586586 Title: Unit test fails because InvocationError Status in Glance: New Bug description: I clone the code of glance from github and check out to version mitaka, then run unit test several times using "tox -e py27 --", each end with "InvocationError": Ran 2999 (+2218) tests in 781.701s (+2.504s) FAILED (id=5, failures=264 (+256), skips=13) error: testr failed (1) ERROR: InvocationError: '/home/yu/openstack/glance/.tox/py27/bin/lockutils-wrapper python setup.py testr --slowest --testr-args=' _ summary __ ERROR: py27: commands failed Is this a bug? To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1586586/+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 1584558] Re: Some config options in codes use double quotes but most of the options use single quotes and that need to be normalized
** No longer affects: ceilometer
** No longer affects: cinder
** No longer affects: nova
--
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/1584558
Title:
Some config options in codes use double quotes but most of the options
use single quotes and that need to be normalized
Status in Glance:
Fix Released
Bug description:
description:
most options like this use '':
volume_manager_opts = [
cfg.StrOpt('volume_driver',
default='cinder.volume.drivers.lvm.LVMISCSIDriver',
help='Driver to use for volume creation'),
cfg.IntOpt('migration_create_volume_timeout_secs',
default=300,
help='Timeout for creating the volume to migrate to '
'when performing volume migration (seconds)'),
cfg.BoolOpt('volume_service_inithost_offload',
default=False,
help='Offload pending volume delete during '
'volume service startup'),
cfg.StrOpt('zoning_mode',
default='none',
help='FC Zoning mode configured'),
cfg.StrOpt('extra_capabilities',
default='{}',
help='User defined capabilities, a JSON formatted string '
'specifying key/value pairs. The key/value pairs can '
'be used by the CapabilitiesFilter to select between '
'backends when requests specify volume types. For '
'example, specifying a service level or the geographical '
'location of a backend, then creating a volume type to '
'allow the user to select by these different '
'properties.'),
]
but some option like this use ""
store_type_opts = [
cfg.ListOpt("store_type_preference",
default=[],
help=_("The store names to use to get store preference order.
"
"The name must be registered by one of the stores "
"defined by the 'stores' config option. "
"This option will be applied when you using "
"'store_type' option as image location strategy "
"defined by the 'location_strategy' config option."))
]
profiler_opts = [
cfg.BoolOpt("enabled", default=False,
help=_('If False fully disable profiling feature.')),
cfg.BoolOpt("trace_sqlalchemy", default=False,
help=_("If False doesn't trace SQL requests."))
]
I think it's need to normalize
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1584558/+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 1584558] Re: Some config options in codes use double quotes but most of the options use single quotes and that need to be normalized
** Also affects: ceilometer
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/1584558
Title:
Some config options in codes use double quotes but most of the options
use single quotes and that need to be normalized
Status in Ceilometer:
In Progress
Status in Cinder:
In Progress
Status in Glance:
Fix Released
Status in heat:
In Progress
Status in OpenStack Compute (nova):
In Progress
Bug description:
description:
most options like this use '':
volume_manager_opts = [
cfg.StrOpt('volume_driver',
default='cinder.volume.drivers.lvm.LVMISCSIDriver',
help='Driver to use for volume creation'),
cfg.IntOpt('migration_create_volume_timeout_secs',
default=300,
help='Timeout for creating the volume to migrate to '
'when performing volume migration (seconds)'),
cfg.BoolOpt('volume_service_inithost_offload',
default=False,
help='Offload pending volume delete during '
'volume service startup'),
cfg.StrOpt('zoning_mode',
default='none',
help='FC Zoning mode configured'),
cfg.StrOpt('extra_capabilities',
default='{}',
help='User defined capabilities, a JSON formatted string '
'specifying key/value pairs. The key/value pairs can '
'be used by the CapabilitiesFilter to select between '
'backends when requests specify volume types. For '
'example, specifying a service level or the geographical '
'location of a backend, then creating a volume type to '
'allow the user to select by these different '
'properties.'),
]
but some option like this use ""
store_type_opts = [
cfg.ListOpt("store_type_preference",
default=[],
help=_("The store names to use to get store preference order.
"
"The name must be registered by one of the stores "
"defined by the 'stores' config option. "
"This option will be applied when you using "
"'store_type' option as image location strategy "
"defined by the 'location_strategy' config option."))
]
profiler_opts = [
cfg.BoolOpt("enabled", default=False,
help=_('If False fully disable profiling feature.')),
cfg.BoolOpt("trace_sqlalchemy", default=False,
help=_("If False doesn't trace SQL requests."))
]
I think it's need to normalize
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1584558/+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 1584558] Re: Some config options in codes use double quotes but most of the options use single quotes and that need to be normalized
** Also affects: cinder
Importance: Undecided
Status: New
** Changed in: cinder
Assignee: (unassigned) => Ji.Wei (jiwei)
** Changed in: cinder
Importance: Undecided => Low
** Also affects: nova
Importance: Undecided
Status: New
** Changed in: nova
Importance: Undecided => Low
** Changed in: nova
Assignee: (unassigned) => jingtao liang (liang-jingtao)
** Also affects: heat
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/1584558
Title:
Some config options in codes use double quotes but most of the options
use single quotes and that need to be normalized
Status in Ceilometer:
In Progress
Status in Cinder:
In Progress
Status in Glance:
Fix Released
Status in heat:
In Progress
Status in OpenStack Compute (nova):
In Progress
Bug description:
description:
most options like this use '':
volume_manager_opts = [
cfg.StrOpt('volume_driver',
default='cinder.volume.drivers.lvm.LVMISCSIDriver',
help='Driver to use for volume creation'),
cfg.IntOpt('migration_create_volume_timeout_secs',
default=300,
help='Timeout for creating the volume to migrate to '
'when performing volume migration (seconds)'),
cfg.BoolOpt('volume_service_inithost_offload',
default=False,
help='Offload pending volume delete during '
'volume service startup'),
cfg.StrOpt('zoning_mode',
default='none',
help='FC Zoning mode configured'),
cfg.StrOpt('extra_capabilities',
default='{}',
help='User defined capabilities, a JSON formatted string '
'specifying key/value pairs. The key/value pairs can '
'be used by the CapabilitiesFilter to select between '
'backends when requests specify volume types. For '
'example, specifying a service level or the geographical '
'location of a backend, then creating a volume type to '
'allow the user to select by these different '
'properties.'),
]
but some option like this use ""
store_type_opts = [
cfg.ListOpt("store_type_preference",
default=[],
help=_("The store names to use to get store preference order.
"
"The name must be registered by one of the stores "
"defined by the 'stores' config option. "
"This option will be applied when you using "
"'store_type' option as image location strategy "
"defined by the 'location_strategy' config option."))
]
profiler_opts = [
cfg.BoolOpt("enabled", default=False,
help=_('If False fully disable profiling feature.')),
cfg.BoolOpt("trace_sqlalchemy", default=False,
help=_("If False doesn't trace SQL requests."))
]
I think it's need to normalize
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1584558/+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 1580831] Re: Unit test: the path of block_devs is wrong in kilo.
** Changed in: nova Status: In Progress => Won't Fix -- 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/1580831 Title: Unit test: the path of block_devs is wrong in kilo. Status in OpenStack Compute (nova): Won't Fix Bug description: In kilo, the path of block_devs is ['/dev/disks/by- path/%s-iscsi-%s-lun-2' % (location, iqn)], but the real path is ['/dev/disk/by-path/%s-iscsi-%s-lun-2' % (location, iqn)] in the nova unit test case: nova.tests.unit.virt.libvirt.test_volume.LibvirtVolumeTestCase.test_libvirt_kvm_volume_with_multipath_still_in_use. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1580831/+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 1581367] [NEW] Changed SAN iscsi IP addresses in connection_info can prevent VM startup
Public bug reported: The iscsi IP addresses of SAN are stored in nova's block-device-mapping table after connecting volume and are never re-validated down the line. Changing the iscsi IP adresses of SAN will prevent the instance from booting as the stale connection info will enter the instance's XML. We should check weather the iscsi IP addresses of SAN are changed before startup VM, or we need to a way to restore those VMs whose iscsi IP addresses of SAN are changed. ** Affects: nova Importance: Undecided Status: New ** Description changed: - The iscsi IP addresses of SAN are stored in nova's block-device-mapping table - after connecting volume and are never re-validated down the line. Changing the - iscsi IP adresses of SAN will prevent the instance from booting as the stale - connection info will enter the instance's XML. We should check weather the - iscsi IP addresses of SAN are changed before startup VM, or we need to a way to - restore those VMs whose iscsi IP addresses of SAN are changed. + The iscsi IP addresses of SAN are stored in nova's block-device-mapping + table after connecting volume and are never re-validated down the line. + Changing the iscsi IP adresses of SAN will prevent the instance from + booting as the stale connection info will enter the instance's XML. We + should check weather the iscsi IP addresses of SAN are changed before + startup VM, or we need to a way to restore those VMs whose iscsi IP + addresses of SAN are changed. -- 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/1581367 Title: Changed SAN iscsi IP addresses in connection_info can prevent VM startup Status in OpenStack Compute (nova): New Bug description: The iscsi IP addresses of SAN are stored in nova's block-device- mapping table after connecting volume and are never re-validated down the line. Changing the iscsi IP adresses of SAN will prevent the instance from booting as the stale connection info will enter the instance's XML. We should check weather the iscsi IP addresses of SAN are changed before startup VM, or we need to a way to restore those VMs whose iscsi IP addresses of SAN are changed. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1581367/+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 1580831] [NEW] Unit test: the path of block_devs is wrong in kilo.
Public bug reported:
In kilo, the path of block_devs is ['/dev/disks/by-
path/%s-iscsi-%s-lun-2' % (location, iqn)], but the real path is
['/dev/disk/by-path/%s-iscsi-%s-lun-2' % (location, iqn)] in the nova
unit test case:
nova.tests.unit.virt.libvirt.test_volume.LibvirtVolumeTestCase.test_libvirt_kvm_volume_with_multipath_still_in_use.
** Affects: nova
Importance: Undecided
Assignee: yuyafei (yu-yafei)
Status: In Progress
** Changed in: nova
Assignee: (unassigned) => yuyafei (yu-yafei)
** Changed in: nova
Status: New => In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1580831
Title:
Unit test: the path of block_devs is wrong in kilo.
Status in OpenStack Compute (nova):
In Progress
Bug description:
In kilo, the path of block_devs is ['/dev/disks/by-
path/%s-iscsi-%s-lun-2' % (location, iqn)], but the real path is
['/dev/disk/by-path/%s-iscsi-%s-lun-2' % (location, iqn)] in the nova
unit test case:
nova.tests.unit.virt.libvirt.test_volume.LibvirtVolumeTestCase.test_libvirt_kvm_volume_with_multipath_still_in_use.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1580831/+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 1540239] [NEW] libvirtError "Failed to open file '/dev/mapper/mpathzy': No such file or directory" when creating a intance with Rally
Public bug reported:
The nova version is Kilo.
When use rally to test intancs booting from volume and deleting, and times is
12 and concurrency is 5.
A intance name intance1 is terminating and now another intance name instance2
is booting from mage(create a new volume).
If intances1 disconnects volume between intance2 connects volume and writes
xml to disk, and supposing there is no intance at the compute node,
Nova will disconnect from iscsi portal if no other multipath devices at the
compute node, it also disconects intances1's iscsi session, then there is no
session or multipath device at the compute node. An error occurred while
trying to launch intances1 with xml: "libvirtError: Failed to open file
'/dev/mapper/mpathzy': No such file or directory"
steps:
1. Preparing the openstack compute node where is no intances or volumes
2. Install Rally.
3. Modify the test case: boot from image(create a new volume) and specify the
compute nodes. Testing times is 12 and concurrency is 5.
(rally)[root@control07 my_senarios]# cat boot-from-volume-and-delete.json
{
"NovaServersVolumeArgs.boot_server_from_volume_and_delete": [
{
"args": {
"flavor": {
"name": "m1.tiny"
},
"image": {
"id": "e77a600c-8f93-4b8d-bd7a-5fe160ecec08"
},
"volume_args": {
"volume_type": "fujitpp"
},
"nics":[{"net-id": "8738a337-9445-49f5-8157-6ec005f355db"}],
"volume_size": 10,
"availability_zone": "nova:compute04"
},
"runner": {
"type": "constant",
"times": 12,
"concurrency": 5
},
"context": {
"users": {
"tenants": 3,
"users_per_tenant": 3
}
}
}
]
}
4. Run the rally.
Expected result:
Rally run successfully
Actual result:
There are several intances lanched failed with error such as "libvirtError:
Failed to open file '/dev/mapper/mpathzy': No such file or directory"
** 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/1540239
Title:
libvirtError "Failed to open file '/dev/mapper/mpathzy': No such file
or directory" when creating a intance with Rally
Status in OpenStack Compute (nova):
New
Bug description:
The nova version is Kilo.
When use rally to test intancs booting from volume and deleting, and times is
12 and concurrency is 5.
A intance name intance1 is terminating and now another intance name instance2
is booting from mage(create a new volume).
If intances1 disconnects volume between intance2 connects volume and
writes xml to disk, and supposing there is no intance at the compute node,
Nova will disconnect from iscsi portal if no other multipath devices at the
compute node, it also disconects intances1's iscsi session, then there is no
session or multipath device at the compute node. An error occurred while
trying to launch intances1 with xml: "libvirtError: Failed to open file
'/dev/mapper/mpathzy': No such file or directory"
steps:
1. Preparing the openstack compute node where is no intances or volumes
2. Install Rally.
3. Modify the test case: boot from image(create a new volume) and specify the
compute nodes. Testing times is 12 and concurrency is 5.
(rally)[root@control07 my_senarios]# cat boot-from-volume-and-delete.json
{
"NovaServersVolumeArgs.boot_server_from_volume_and_delete": [
{
"args": {
"flavor": {
"name": "m1.tiny"
},
"image": {
"id": "e77a600c-8f93-4b8d-bd7a-5fe160ecec08"
},
"volume_args": {
"volume_type": "fujitpp"
},
"nics":[{"net-id": "8738a337-9445-49f5-8157-6ec005f355db"}],
"volume_size": 10,
"availability_zone": "nova:compute04"
},
"runner": {
"type": "constant",
"times": 12,
"concurrency": 5
},
"context": {
"users": {
"tenants": 3,
"users_per_tenant": 3
}
}
}
]
}
4. Run the rally.
Expected result:
Rally run successfully
Actual result:
There are several intances lanched failed with error such as "libvirtError:
Failed to open file '/dev/mapper/mpathzy': No such file or directory"
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/15
