[Yahoo-eng-team] [Bug 1530249] [NEW] Use six.moves.reduce instead of builtin reduce

[HouMing Wang]

Public bug reported:

Builtin function 'reduce' in Python 2 has been moved to standard
library module in Python 3 [1]. To make code compatible, we should
replace reduce(expr) with six.moves.reduce(expr)

[1] http://python3porting.com/stdlib.html#moved-builtins

** Affects: glance
 Importance: Undecided
 Assignee: HouMing Wang (houming-wang)
 Status: In Progress

** Changed in: glance
 Assignee: (unassigned) => HouMing Wang (houming-wang)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1530249

Title:
   Use six.moves.reduce instead of builtin reduce

Status in Glance:
  In Progress

Bug description:
  Builtin function 'reduce' in Python 2 has been moved to standard
  library module in Python 3 [1]. To make code compatible, we should
  replace reduce(expr) with six.moves.reduce(expr)

  [1] http://python3porting.com/stdlib.html#moved-builtins

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1530249/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1530249] Re: Use six.moves.reduce instead of builtin reduce

[HouMing Wang]

** Changed in: cinder
   Status: In Progress => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1530249

Title:
   Use six.moves.reduce instead of builtin reduce

Status in Cinder:
  Invalid
Status in Glance:
  In Progress

Bug description:
  Builtin function 'reduce' in Python 2 has been moved to standard
  library module in Python 3 [1]. To make code compatible, we should
  replace reduce(expr) with six.moves.reduce(expr)

  [1] http://python3porting.com/stdlib.html#moved-builtins

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1530249/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1530249] Re: Use six.moves.reduce instead of builtin reduce

[LiuNanke]

** Also affects: cinder
   Importance: Undecided
   Status: New

** Changed in: cinder
 Assignee: (unassigned) => LiuNanke (nanke-liu)

** Changed in: cinder
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1530249

Title:
   Use six.moves.reduce instead of builtin reduce

Status in Cinder:
  In Progress
Status in Glance:
  In Progress

Bug description:
  Builtin function 'reduce' in Python 2 has been moved to standard
  library module in Python 3 [1]. To make code compatible, we should
  replace reduce(expr) with six.moves.reduce(expr)

  [1] http://python3porting.com/stdlib.html#moved-builtins

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1530249/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1530275] [NEW] Live snapshot is corrupted (possibly race condition?)

[Favyen Bastani]

Public bug reported:

We are using nova 2:12.0.0-0ubuntu2~cloud0. Instance disks are stored in
qcow2 files on ext4 filesystem. When we live snapshot, 90% of the time
the produced image is corrupted; specifically, the image is only a few
megabytes (e.g. 30 MB) in size, while the disk size is several GB. Here
is the log from a corrupted snapshot:

2015-12-31 01:40:33.304 16805 INFO nova.compute.manager 
[req-80187ec9-a3e7-4eaf-80d4-1617da40989e 94b1e02c35204ca89bd5aea99ff5ef2b 
8341c85ad9ae49408fa25074adba0480 - - -] [instance: 
f9d52a00-8466-4436-b5b4-f0244d54dfe1] instance snapshotting
2015-12-31 01:40:33.410 16805 INFO nova.virt.libvirt.driver 
[req-80187ec9-a3e7-4eaf-80d4-1617da40989e 94b1e02c35204ca89bd5aea99ff5ef2b 
8341c85ad9ae49408fa25074adba0480 - - -] [instance: 
f9d52a00-8466-4436-b5b4-f0244d54dfe1] Beginning live snapshot process
2015-12-31 01:40:34.964 16805 INFO nova.virt.libvirt.driver 
[req-80187ec9-a3e7-4eaf-80d4-1617da40989e 94b1e02c35204ca89bd5aea99ff5ef2b 
8341c85ad9ae49408fa25074adba0480 - - -] [instance: 
f9d52a00-8466-4436-b5b4-f0244d54dfe1] Snapshot extracted, beginning image upload
2015-12-31 01:40:37.029 16805 INFO nova.virt.libvirt.driver 
[req-80187ec9-a3e7-4eaf-80d4-1617da40989e 94b1e02c35204ca89bd5aea99ff5ef2b 
8341c85ad9ae49408fa25074adba0480 - - -] [instance: 
f9d52a00-8466-4436-b5b4-f0244d54dfe1] Snapshot image upload complete

The entire operation completes in a couple of seconds, which is
unexpected.

While testing, I added some sleep calls to the _live_snapshot function
in virt/libvirt/driver.py to debug the problem. A few live snapshot runs
were successful, but I'm not confident that it fixed the problem.
Anyway, here is the code that I changed:

try:
# NOTE (rmk): blockRebase cannot be executed on persistent
# domains, so we need to temporarily undefine it.
# If any part of this block fails, the domain is
# re-defined regardless.
if guest.has_persistent_configuration():
guest.delete_configuration()

# NOTE (rmk): Establish a temporary mirror of our root disk and
# issue an abort once we have a complete copy.
dev.rebase(disk_delta, copy=True, reuse_ext=True, shallow=True)

+time.sleep(10.0)
while dev.wait_for_job():
-time.sleep(0.5)
+time.sleep(5.0)

dev.abort_job()
libvirt_utils.chown(disk_delta, os.getuid())
finally:
self._host.write_instance_config(xml)
if require_quiesce:
self.unquiesce(context, instance, image_meta)

And the resulting log (which indicates that it is sleeping for not just
the initial 10 second call, but even more than that):

2015-12-31 01:42:12.438 21232 INFO nova.compute.manager 
[req-f3cc4b5b-98b0-4315-b514-de36a07cb8ed 94b1e02c35204ca89bd5aea99ff5ef2b 
8341c85ad9ae49408fa25074adba0480 - - -] [instance: 
f9d52a00-8466-4436-b5b4-f0244d54dfe1] instance snapshotting
2015-12-31 01:42:12.670 21232 INFO nova.virt.libvirt.driver 
[req-f3cc4b5b-98b0-4315-b514-de36a07cb8ed 94b1e02c35204ca89bd5aea99ff5ef2b 
8341c85ad9ae49408fa25074adba0480 - - -] [instance: 
f9d52a00-8466-4436-b5b4-f0244d54dfe1] Beginning live snapshot process
2015-12-31 01:43:02.411 21232 INFO nova.virt.libvirt.driver 
[req-f3cc4b5b-98b0-4315-b514-de36a07cb8ed 94b1e02c35204ca89bd5aea99ff5ef2b 
8341c85ad9ae49408fa25074adba0480 - - -] [instance: 
f9d52a00-8466-4436-b5b4-f0244d54dfe1] Snapshot extracted, beginning image upload
2015-12-31 01:44:12.893 21232 INFO nova.virt.libvirt.driver 
[req-f3cc4b5b-98b0-4315-b514-de36a07cb8ed 94b1e02c35204ca89bd5aea99ff5ef2b 
8341c85ad9ae49408fa25074adba0480 - - -] [instance: 
f9d52a00-8466-4436-b5b4-f0244d54dfe1] Snapshot image upload complete

Since sleeping 10 seconds before polling wait_for_job seemed to resolve
it, I think there may be a race condition where wait_for_job may be
called before the job is fully initialized from the rebase call. I have
not had a chance to explore that possibility further though.

** Affects: nova
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1530275

Title:
  Live snapshot is corrupted (possibly race condition?)

Status in OpenStack Compute (nova):
  New

Bug description:
  We are using nova 2:12.0.0-0ubuntu2~cloud0. Instance disks are stored
  in qcow2 files on ext4 filesystem. When we live snapshot, 90% of the
  time the produced image is corrupted; specifically, the image is only
  a few megabytes (e.g. 30 MB) in size, while the disk size is several
  GB. Here is the log from a corrupted snapshot:

  2015-12-31 01:40:33.304 16805 INFO nova.compute.manager 
[req-80187ec9-a3e7-4eaf-80d4-1617da40989e 94b1e02c35204ca89bd5aea99ff5ef2b 

[Yahoo-eng-team] [Bug 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()

[Shuquan Huang]

** Also affects: congress
   Importance: Undecided
   Status: New

** Changed in: congress
 Assignee: (unassigned) => Shuquan Huang (shuquan)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1268480

Title:
  assertTrue(isinstance()) in tests should be replace with
  assertIsInstance()

Status in Barbican:
  In Progress
Status in Ceilometer:
  Fix Released
Status in Cinder:
  In Progress
Status in CloudRoast:
  New
Status in congress:
  In Progress
Status in Glance:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Invalid
Status in OpenStack Compute (nova):
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  some of tests use different method of assertTrue(isinstance(A, B)) or
  assertEqual(type(A), B). The correct way is to use assertIsInstance(A,
  B) provided by testtools

To manage notifications about this bug go to:
https://bugs.launchpad.net/barbican/+bug/1268480/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1529534] Re: User new log style where Logger.exception() is used by passing an exception object as the first argument.

[Sean McGinnis]

This is invalid. An exception object should not be passed to
log.exception. That logs whatever exception is in scope, so passing in
the exception results in it being logged twice.

If passing to log.error, six.text_type is recommended.

** Changed in: cinder
   Status: In Progress => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1529534

Title:
  User new log style where Logger.exception() is used by passing an
  exception object as the first argument.

Status in Ceilometer:
  New
Status in Cinder:
  Invalid
Status in Gnocchi:
  In Progress
Status in Ironic:
  In Progress
Status in Magnum:
  In Progress
Status in Manila:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in python-ceilometerclient:
  New
Status in python-glanceclient:
  New
Status in python-gnocchiclient:
  In Progress
Status in python-keystoneclient:
  New
Status in python-neutronclient:
  Confirmed
Status in python-troveclient:
  New
Status in Sahara:
  New
Status in Trove:
  New

Bug description:
  Use new log style where Logger.exception() is used by passing an
  exception object as the first argument[1].

  [1]http://docs.openstack.org/developer/oslo.log/usage.html#no-more-
  implicit-conversion-to-unicode-str

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1529534/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1528393] Re: signature_utils tests fail on Fedora/RHEL/CentOS because not all ECC curves are available

[OpenStack Infra]

Reviewed:  https://review.openstack.org/260277
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=291e71990a0866836d1becea6d519df9abaaa186
Submitter: Jenkins
Branch:master

commit 291e71990a0866836d1becea6d519df9abaaa186
Author: Mark McLoughlin 
Date:   Mon Dec 21 23:54:17 2015 +

signature_utils: handle ECC curve unavailability

Some ECC curves are unavailable on some platforms (like Fedora, RHEL,
and CentOS) because of legal concerns. See the bug report for more
details and history.

The cryptography backend has a elliptic_curve_supported() method
which we can use to avoid curves which are unavailable on the current
platform.

If an image signature uses one of these curves, we will return an
"Invalid signature key type" error.

Use the warnings module in the unit tests to avoid silently ignoring
this issue during testing. This warning will be captured from the
test's stderr and reported by testr.

Closes-Bug: #1528393

Change-Id: Ie25311c48b276f300fadaf1815fc4df4cb89cf8d
Signed-off-by: Mark McLoughlin 


** Changed in: nova
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1528393

Title:
  signature_utils tests fail on Fedora/RHEL/CentOS because not all ECC
  curves are available

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Not all ECC curves we use in signature_utils are available on all
  platforms - e.g.

  On RHEL 7.2

$ openssl ecparam -list_curves
secp384r1 : NIST/SECG curve over a 384 bit prime field
secp521r1 : NIST/SECG curve over a 521 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field

  On Fedora 23 ...

$ openssl ecparam -list_curves
secp256k1 : SECG curve over a 256 bit prime field
secp384r1 : NIST/SECG curve over a 384 bit prime field
secp521r1 : NIST/SECG curve over a 521 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field

  There's a long history surrounding the lack of ECC support in openssl
  in Fedora, RHEL, and CentOS because of legal issues - see
  https://bugzilla.redhat.com/show_bug.cgi?id=319901

  Some ECC curves are now available, but each additional one requested
  will be considered individually - there is a tracker bug for this:
  https://bugzilla.redhat.com/showdependencytree.cgi?id=1019390_resolved=0

  This is the failure I'm seeing since
  https://review.openstack.org/#/c/256069/ was merged

  
nova.tests.unit.test_signature_utils.TestSignatureUtils.test_verify_signature_ECC
  
-

  Captured traceback:
  ~~~
  Traceback (most recent call last):
File 
"/home/markmc/git/openstack/nova/.tox/py27/lib/python2.7/site-packages/mock/mock.py",
 line 1305, in patched
  return func(*args, **keywargs)
File "nova/tests/unit/test_signature_utils.py", line 178, in 
test_verify_signature_ECC
  default_backend())
File 
"/home/markmc/git/openstack/nova/.tox/py27/lib/python2.7/site-packages/cryptography/hazmat/primitives/asymmetric/ec.py",
 line 241, in generate_private_key
  return backend.generate_elliptic_curve_private_key(curve)
File 
"/home/markmc/git/openstack/nova/.tox/py27/lib/python2.7/site-packages/cryptography/hazmat/backends/multibackend.py",
 line 247, in generate_elliptic_curve_private_key
  _Reasons.UNSUPPORTED_ELLIPTIC_CURVE
  cryptography.exceptions.UnsupportedAlgorithm: This backend does not 
support this elliptic curve.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1528393/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1530179] [NEW] get_subnet_for_dvr() returns wrong gateway mac

[Oleg Bondarev]

Public bug reported:

get_subnet_for_dvr should return proper gateway mac address in order for ovs 
agent to add proper flows for dvr interface on br-int.
commit e82b0e108332964c90e9d2cfaf3d334a92127155 added 'fixed_ips' parameter to 
the handler to filter gateway port of the subnet. However actual filtering was 
applied improperly which leads to wrong gateway mac being returned:
   
if fixed_ips:
filter = fixed_ips[0]
else:
filter = {'fixed_ips': {'subnet_id': [subnet],
'ip_address':
[subnet_info['gateway_ip']]}}

internal_gateway_ports = self.plugin.get_ports(
context, filters=filter)

internal_port = internal_gateway_ports[0]
subnet_info['gateway_mac'] = internal_port['mac_address']

get_ports() here actually returns _all_ ports so mac address of a random
port is returned as 'gateway_mac'. In most cases it doesn't lead to any
noticeable side effects but in some cases it may cause very weird
behavior.

The case that we faced was:
 root@node-9:~# ovs-ofctl dump-flows br-int
 ...
 cookie=0x971c69a135b8ce1f, duration=23023.412s, table=2, n_packets=1339, 
n_bytes=131234, idle_age=19050, 
priority=4,dl_vlan=3556,dl_dst=fa:16:3e:da:53:f1 
actions=strip_vlan,mod_dl_src:fa:16:3e:2c:24:86,output:6
 cookie=0x971c69a135b8ce1f, duration=31946.414s, table=2, n_packets=25320, 
n_bytes=2481408, idle_age=1, priority=4,dl_vlan=3556,dl_dst=fa:16:3e:2c:24:86 
actions=strip_vlan,mod_dl_src:fa:16:3e:2c:24:86,output:5
 ...

fa:16:3e:2c:24:86 is mac address of a vm port and it was returned as
gateway mac due to the bug. This vm was unreachable from other subnets
connected to the same dvr router. However another vm on the same host
and the same subnet was ok. It took a while to find out what was wrong
:)

** Affects: neutron
 Importance: Medium
 Assignee: Oleg Bondarev (obondarev)
 Status: New


** Tags: l3-dvr-backlog

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1530179

Title:
  get_subnet_for_dvr() returns wrong gateway mac

Status in neutron:
  New

Bug description:
  get_subnet_for_dvr should return proper gateway mac address in order for ovs 
agent to add proper flows for dvr interface on br-int.
  commit e82b0e108332964c90e9d2cfaf3d334a92127155 added 'fixed_ips' parameter 
to the handler to filter gateway port of the subnet. However actual filtering 
was applied improperly which leads to wrong gateway mac being returned:
 
  if fixed_ips:
  filter = fixed_ips[0]
  else:
  filter = {'fixed_ips': {'subnet_id': [subnet],
  'ip_address':
  [subnet_info['gateway_ip']]}}

  internal_gateway_ports = self.plugin.get_ports(
  context, filters=filter)

  internal_port = internal_gateway_ports[0]
  subnet_info['gateway_mac'] = internal_port['mac_address']

  get_ports() here actually returns _all_ ports so mac address of a
  random port is returned as 'gateway_mac'. In most cases it doesn't
  lead to any noticeable side effects but in some cases it may cause
  very weird behavior.

  The case that we faced was:
   root@node-9:~# ovs-ofctl dump-flows br-int
   ...
   cookie=0x971c69a135b8ce1f, duration=23023.412s, table=2, n_packets=1339, 
n_bytes=131234, idle_age=19050, 
priority=4,dl_vlan=3556,dl_dst=fa:16:3e:da:53:f1 
actions=strip_vlan,mod_dl_src:fa:16:3e:2c:24:86,output:6
   cookie=0x971c69a135b8ce1f, duration=31946.414s, table=2, n_packets=25320, 
n_bytes=2481408, idle_age=1, priority=4,dl_vlan=3556,dl_dst=fa:16:3e:2c:24:86 
actions=strip_vlan,mod_dl_src:fa:16:3e:2c:24:86,output:5
   ...

  fa:16:3e:2c:24:86 is mac address of a vm port and it was returned as
  gateway mac due to the bug. This vm was unreachable from other subnets
  connected to the same dvr router. However another vm on the same host
  and the same subnet was ok. It took a while to find out what was wrong
  :)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1530179/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1529836] Re: Fix deprecated library function (os.popen()).

[Harshada Mangesh Kakad]

** Changed in: manila
 Assignee: Abhishek Kekane (abhishek-kekane) => Harshada Mangesh Kakad 
(harshada-kakad)

** Changed in: cinder
 Assignee: Abhishek Kekane (abhishek-kekane) => Harshada Mangesh Kakad 
(harshada-kakad)

** Changed in: keystone
 Assignee: Abhishek Kekane (abhishek-kekane) => Harshada Mangesh Kakad 
(harshada-kakad)

** Changed in: cinder
   Status: New => In Progress

** Changed in: manila
   Status: New => In Progress

** Changed in: keystone
   Status: New => In Progress

** Also affects: glance
   Importance: Undecided
   Status: New

** Changed in: glance
 Assignee: (unassigned) => Harshada Mangesh Kakad (harshada-kakad)

** Changed in: glance
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1529836

Title:
  Fix deprecated library function (os.popen()).

Status in Cinder:
  In Progress
Status in devstack:
  In Progress
Status in Glance:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in Manila:
  In Progress
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in oslo-incubator:
  In Progress
Status in OpenStack Object Storage (swift):
  In Progress
Status in tempest:
  In Progress

Bug description:
  Deprecated library function os.popen is still in use at some places.
  Need to replace it using subprocess module.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1529836/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

[OpenStack Infra]

Reviewed:  https://review.openstack.org/261415
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=aed4d660984adaf70eccce36066d56973939027b
Submitter: Jenkins
Branch:master

commit aed4d660984adaf70eccce36066d56973939027b
Author: LiuNanke 
Date:   Fri Dec 25 13:33:35 2015 +0800

Replace assertEqual(None,*) with assertIsNone

Replace assertEqual(None, *) with assertIsNone in
tests to have more clear messages in case of failure.

Closes-Bug: #1280522

Change-Id: I950881a51053d83762c941d813da6bbf9f8578c9


** Changed in: horizon
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in Cinder:
  Fix Released
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  In Progress
Status in Heat Translator:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  In Progress
Status in OpenStack Compute (nova):
  Fix Released
Status in os-client-config:
  Fix Released
Status in python-barbicanclient:
  In Progress
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  In Progress
Status in python-cueclient:
  In Progress
Status in python-designateclient:
  In Progress
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  In Progress
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  In Progress
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  In Progress
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Sahara:
  Fix Released
Status in Solum:
  In Progress
Status in tempest:
  Fix Released
Status in Trove:
  Fix Released
Status in tuskar:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1528382] Re: default theme's warning color is not readable

[OpenStack Infra]

Reviewed:  https://review.openstack.org/260245
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=bffc1a645e23b71d934002ab81ff56fe8c9a43e9
Submitter: Jenkins
Branch:master

commit bffc1a645e23b71d934002ab81ff56fe8c9a43e9
Author: Diana Whitten 
Date:   Mon Dec 21 16:30:29 2015 -0700

default theme's warning color is not readable

It was far too bright to make out with white lettering.

Change-Id: Ib3695cc630fb41df4a3bd63506f1ba705bf940a8
Closes-bug: #1528382


** Changed in: horizon
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1528382

Title:
  default theme's warning color is not readable

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Its far too light:

  
https://www.dropbox.com/s/f6cl12jfdxd4llr/Screenshot%202015-12-21%2016.26.48.png?dl=0

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1528382/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1529534] Re: User new log style where Logger.exception() is used by passing an exception object as the first argument.

[OpenStack Infra]

Change abandoned by LiuNanke (nanke@easystack.cn) on branch: master
Review: https://review.openstack.org/262263

** Changed in: cinder
   Status: Invalid => In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1529534

Title:
  User new log style where Logger.exception() is used by passing an
  exception object as the first argument.

Status in Ceilometer:
  New
Status in Cinder:
  In Progress
Status in Gnocchi:
  In Progress
Status in Ironic:
  In Progress
Status in Magnum:
  In Progress
Status in Manila:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in python-ceilometerclient:
  New
Status in python-glanceclient:
  New
Status in python-gnocchiclient:
  In Progress
Status in python-keystoneclient:
  New
Status in python-neutronclient:
  Confirmed
Status in python-troveclient:
  New
Status in Sahara:
  New
Status in Trove:
  New

Bug description:
  Use new log style where Logger.exception() is used by passing an
  exception object as the first argument[1].

  [1]http://docs.openstack.org/developer/oslo.log/usage.html#no-more-
  implicit-conversion-to-unicode-str

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1529534/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1529913] Re: use warning to avoid DeprecationWarning

[OpenStack Infra]

Reviewed:  https://review.openstack.org/262232
Committed: 
https://git.openstack.org/cgit/openstack/trove/commit/?id=1ee6814457e454dd86d263563d7cadd15dce3113
Submitter: Jenkins
Branch:master

commit 1ee6814457e454dd86d263563d7cadd15dce3113
Author: LiuNanke 
Date:   Tue Dec 29 22:45:10 2015 +0800

Using LOG.warning replace LOG.warn

*Python 3 deprecated the logger.warn method, see:
*https://docs.python.org/3/library/logging.html#logging.warning
*so we prefer to use warning to avoid DeprecationWarning.

Closes-Bug: #1529913

Change-Id: Iae9e13e89bb9566c2482017f631408a95ffe002d


** Changed in: trove
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1529913

Title:
  use warning to avoid DeprecationWarning

Status in Glance:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in Manila:
  New
Status in OpenStack Compute (nova):
  In Progress
Status in Trove:
  Fix Released

Bug description:
  Python 3 deprecated the logger.warn method, see:

  https://docs.python.org/3/library/logging.html#logging.warning

  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1529913/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1530214] Re: Tempest failures due to iSCSI DB failure on compute node

[John Griffith]

** Also affects: os-brick
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1530214

Title:
  Tempest failures due to iSCSI DB failure on compute node

Status in OpenStack Compute (nova):
  New
Status in os-brick:
  New

Bug description:
  Noticed a couple of these today in the SolidFire CI system.  These are 
initiator side errors in Nova.  Excerpt from log is below, but additional logs 
can also be viewed here:
  
http://54.164.167.86/solidfire-ci-logs/refs-changes-67-244867-12/logs/screen-n-cpu.log.txt


  2015-12-30 20:53:50.829 ERROR nova.virt.block_device 
[req-0f1602ac-0604-4051-8d65-81ede0976dc5 
tempest-DeleteServersTestJSON-1052804341 
tempest-DeleteServersTestJSON-308638552] [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] Driver failed to attach volume 
23049317-f6c2-40b2-9306-0b838848f911 at /dev/vdb
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] Traceback (most recent call last):
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/nova/nova/virt/block_device.py", line 288, in attach
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] device_type=self['device_type'], 
encryption=encryption)
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 1114, in attach_volume
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] self._connect_volume(connection_info, 
disk_info)
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 1064, in _connect_volume
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] 
vol_driver.connect_volume(connection_info, disk_info)
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/nova/nova/virt/libvirt/volume/iscsi.py", line 84, in connect_volume
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] device_info = 
self.connector.connect_volume(connection_info['data'])
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 
271, in inner
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] return f(*args, **kwargs)
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/os-brick/os_brick/initiator/connector.py", line 763, in 
connect_volume
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] connection_properties)
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/os-brick/os_brick/initiator/connector.py", line 591, in 
_get_potential_volume_paths
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] if 
self._connect_to_iscsi_portal(props):
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/os-brick/os_brick/initiator/connector.py", line 1044, in 
_connect_to_iscsi_portal
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] 
self._run_iscsiadm(connection_properties, ())
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/os-brick/os_brick/initiator/connector.py", line 948, in 
_run_iscsiadm
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] delay_on_retry=delay_on_retry)
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", line 
312, in execute
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] cmd=sanitized_cmd)
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] ProcessExecutionError: Unexpected error 
while running command.
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 

[Yahoo-eng-team] [Bug 1530214] Re: Tempest failures due to iSCSI DB failure on compute node

[John Griffith]

*** This bug is a duplicate of bug 1324670 ***
https://bugs.launchpad.net/bugs/1324670

Looks like this is an old one we thought was fixed on the brick side.  Removing 
Nova and marking as a duplicate of the original bug:
1324670


** No longer affects: nova

** This bug has been marked a duplicate of bug 1324670
   'iscsiadm ... -o delete' fails occasionally on bulk deployments

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1530214

Title:
  Tempest failures due to iSCSI DB failure on compute node

Status in os-brick:
  New

Bug description:
  Noticed a couple of these today in the SolidFire CI system.  These are 
initiator side errors in Nova.  Excerpt from log is below, but additional logs 
can also be viewed here:
  
http://54.164.167.86/solidfire-ci-logs/refs-changes-67-244867-12/logs/screen-n-cpu.log.txt


  2015-12-30 20:53:50.829 ERROR nova.virt.block_device 
[req-0f1602ac-0604-4051-8d65-81ede0976dc5 
tempest-DeleteServersTestJSON-1052804341 
tempest-DeleteServersTestJSON-308638552] [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] Driver failed to attach volume 
23049317-f6c2-40b2-9306-0b838848f911 at /dev/vdb
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] Traceback (most recent call last):
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/nova/nova/virt/block_device.py", line 288, in attach
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] device_type=self['device_type'], 
encryption=encryption)
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 1114, in attach_volume
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] self._connect_volume(connection_info, 
disk_info)
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 1064, in _connect_volume
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] 
vol_driver.connect_volume(connection_info, disk_info)
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/nova/nova/virt/libvirt/volume/iscsi.py", line 84, in connect_volume
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] device_info = 
self.connector.connect_volume(connection_info['data'])
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 
271, in inner
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] return f(*args, **kwargs)
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/os-brick/os_brick/initiator/connector.py", line 763, in 
connect_volume
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] connection_properties)
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/os-brick/os_brick/initiator/connector.py", line 591, in 
_get_potential_volume_paths
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] if 
self._connect_to_iscsi_portal(props):
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/os-brick/os_brick/initiator/connector.py", line 1044, in 
_connect_to_iscsi_portal
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] 
self._run_iscsiadm(connection_properties, ())
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/os-brick/os_brick/initiator/connector.py", line 948, in 
_run_iscsiadm
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] delay_on_retry=delay_on_retry)
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", line 
312, in execute
  2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]

[Yahoo-eng-team] [Bug 1530214] [NEW] Tempest failures due to iSCSI DB failure on compute node

[John Griffith]

Public bug reported:

Noticed a couple of these today in the SolidFire CI system.  These are 
initiator side errors in Nova.  Excerpt from log is below, but additional logs 
can also be viewed here:
http://54.164.167.86/solidfire-ci-logs/refs-changes-67-244867-12/logs/screen-n-cpu.log.txt


2015-12-30 20:53:50.829 ERROR nova.virt.block_device 
[req-0f1602ac-0604-4051-8d65-81ede0976dc5 
tempest-DeleteServersTestJSON-1052804341 
tempest-DeleteServersTestJSON-308638552] [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] Driver failed to attach volume 
23049317-f6c2-40b2-9306-0b838848f911 at /dev/vdb
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] Traceback (most recent call last):
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/nova/nova/virt/block_device.py", line 288, in attach
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] device_type=self['device_type'], 
encryption=encryption)
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 1114, in attach_volume
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] self._connect_volume(connection_info, 
disk_info)
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 1064, in _connect_volume
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] 
vol_driver.connect_volume(connection_info, disk_info)
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/nova/nova/virt/libvirt/volume/iscsi.py", line 84, in connect_volume
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] device_info = 
self.connector.connect_volume(connection_info['data'])
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 
271, in inner
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] return f(*args, **kwargs)
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/os-brick/os_brick/initiator/connector.py", line 763, in 
connect_volume
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] connection_properties)
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/os-brick/os_brick/initiator/connector.py", line 591, in 
_get_potential_volume_paths
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] if 
self._connect_to_iscsi_portal(props):
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/os-brick/os_brick/initiator/connector.py", line 1044, in 
_connect_to_iscsi_portal
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] 
self._run_iscsiadm(connection_properties, ())
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/opt/stack/os-brick/os_brick/initiator/connector.py", line 948, in 
_run_iscsiadm
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] delay_on_retry=delay_on_retry)
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c]   File 
"/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", line 
312, in execute
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] cmd=sanitized_cmd)
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] ProcessExecutionError: Unexpected error 
while running command.
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] Command: sudo nova-rootwrap 
/etc/nova/rootwrap.conf iscsiadm -m node -T 
iqn.2010-01.com.solidfire:l74j.uuid-23049317-f6c2-40b2-9306-0b838848f911.374375 
-p 10.10.64.3:3260
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] Exit code: 6
2015-12-30 20:53:50.829 13456 ERROR nova.virt.block_device [instance: 
d1526309-a49f-46b3-9a29-7d7ae285be9c] 

[Yahoo-eng-team] [Bug 1521360] Re: Add Member action in loadbalancers does not enforce protocol as required field

[OpenStack Infra]

Reviewed:  https://review.openstack.org/252409
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=5d384cb18da4e274e63938916d941f367b564386
Submitter: Jenkins
Branch:master

commit 5d384cb18da4e274e63938916d941f367b564386
Author: Tatiana Ovchinnikova 
Date:   Wed Dec 2 16:50:53 2015 +0300

Protocol port should be required for LBaaS Add Member

Protocol port field should be required for LBaaS Add Member action,
no matter what member source is chosen. This patch set also fixes
members field's label for the case when there is no available servers.

Change-Id: Ib0a00a2b7acdbb0d3dd454e54122ec601889a1fc
Closes-Bug: #1521360


** Changed in: horizon
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1521360

Title:
  Add Member action in loadbalancers does not enforce protocol as
  required field

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  In Project->Networks->Load Balancers:

  1. Click on Members tab
  2. Click on 'Add Member' button

  **Make sure there are no instances to be added as members.**

  Protocol Port is not a required field but if you don't enter the port,
  it fails with message "Unable to add members" which does not  indicate
  the actual error.

  Horizon log shows this error:
  2015-11-30 21:09:39,964 DEBUG 25947 [neutronclient.client]: RESP:400 {'date': 
'Mon, 30 Nov 2015 21:09:39 GMT', 'connection': 'keep-alive', 'content-type': 
'application/json; charset=UTF-8', 'content-length': '124', 
'x-openstack-request-id': 'req-e140a1b7-72dd-46d1-9033-159d1897988a'} 
{"NeutronError": {"message": "Invalid input for operation: 'None' is not a 
integer.", "type": "InvalidInput", "detail": ""}}

  2015-11-30 21:09:39,964 DEBUG 25947 [neutronclient.v2_0.client]: Error
  message: {"NeutronError": {"message": "Invalid input for operation:
  'None' is not a integer.", "type": "InvalidInput", "detail": ""}}

  Neutron Log shows the following error:
  2015-11-30 21:09:39,961DEBUG [neutron.api.v2.base] 597 Request body: 
{u'member': {u'protocol_port': None, u'pool_id': 
u'b4996970-2d8f-4d9f-b553-a55bf1a159d0', u'address': u'10.2.2.5', 
u'admin_state_up': True}}
  2015-11-30 21:09:39,962 INFO [neutron.api.v2.resource] 95 create failed 
(client error): Invalid input for operation: 'None' is not a integer.

  Looks like the underlying problem is that protocol_port is removed as
  a requirement when there are no instances available to be selected as
  members. However, user can still choose the other way of entering the
  member ip address and will run into this problem
  (protocol_port.required will still be set to False as there are no
  servers).

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1521360/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1529534] Re: User new log style where Logger.exception() is used by passing an exception object as the first argument.

[HouMing Wang]

** No longer affects: manila

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1529534

Title:
  User new log style where Logger.exception() is used by passing an
  exception object as the first argument.

Status in Ceilometer:
  New
Status in Cinder:
  In Progress
Status in Gnocchi:
  In Progress
Status in Ironic:
  In Progress
Status in Magnum:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in python-ceilometerclient:
  New
Status in python-glanceclient:
  New
Status in python-gnocchiclient:
  In Progress
Status in python-keystoneclient:
  New
Status in python-neutronclient:
  Confirmed
Status in python-troveclient:
  New
Status in Sahara:
  New
Status in Trove:
  New

Bug description:
  Use new log style where Logger.exception() is used by passing an
  exception object as the first argument[1].

  [1]http://docs.openstack.org/developer/oslo.log/usage.html#no-more-
  implicit-conversion-to-unicode-str

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1529534/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1530249] Re: Use six.moves.reduce instead of builtin reduce

[LiuNanke]

** No longer affects: cinder

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1530249

Title:
   Use six.moves.reduce instead of builtin reduce

Status in Glance:
  In Progress

Bug description:
  Builtin function 'reduce' in Python 2 has been moved to standard
  library module in Python 3 [1]. To make code compatible, we should
  replace reduce(expr) with six.moves.reduce(expr)

  [1] http://python3porting.com/stdlib.html#moved-builtins

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1530249/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1276694] Re: Openstack services should support SIGHUP signal

[Steve Martinelli]

I think keystone gets this for free since we're using oslo.service
(https://github.com/openstack/keystone/blob/master/requirements.txt#L32)
for eventlet.

for the case of running keystone under httpd, i think most support
SIGHUP: https://httpd.apache.org/docs/2.2/en/stopping.html

** Changed in: keystone
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1276694

Title:
  Openstack services should support SIGHUP signal

Status in Glance:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Identity (keystone):
  Invalid
Status in Murano:
  Confirmed
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  Fix Released
Status in oslo-incubator:
  Invalid
Status in oslo.config:
  New
Status in oslo.log:
  New
Status in oslo.service:
  Fix Released
Status in Sahara:
  In Progress

Bug description:
  1)In order to more effectively manage the unlinked and open (lsof +L1)
  log files descriptors w/o restarting the services, SIGHUP signal
  should be accepted by every Openstack service.

  That would allow, e.g. logrotate jobs to gracefully HUP services after
  their log files were rotated. The only option we have for now is to
  force the services restart, quite a poor option from the services
  continuous accessibility PoV.

  Note: according to  http://en.wikipedia.org/wiki/Unix_signal
  SIGHUP
     ... Many daemons will reload their configuration files and reopen their 
logfiles instead of exiting when receiving this signal.

  Currently Murano and Glance are out of sync with Oslo SIGHUP support.

  There is also the following issue exists for some of the services of OS 
projects with synced SIGHUP support:
  2)
  heat-api-cfn, heat-api, heat-api-cloudwatch, keystone:  looks like the synced 
code is never being executed, thus SIGHUP is not supported for them. Here is a 
simple test scenario:
  2.1) modify 
/site-packages//openstack/common/service.py
  def _sighup_supported():
  +LOG.warning("SIGHUP is supported: {0}".format(hasattr(signal, 'SIGHUP')))
  return hasattr(signal, 'SIGHUP')
  2.2) restart service foo-service-name and check logs for "SIGHUP is 
supported", if service  really supports it, the appropriate messages would be 
present in the logs.
  2.3) issue kill -HUP  and check logs for "SIGHUP is 
supported" and "Caught SIGHUP", if service  really supports it, the appropriate 
messages would be present in the logs. Besides that, the service should remain 
started and its main thread PID should not be changed.

  e.g.
  2.a) heat-engine supports HUPing:
  #service openstack-heat-engine restart
  <132>Apr 11 14:03:48 node-3 heat-heat.openstack.common.service WARNING: 
SIGHUP is supported: True

  2.b)But heat-api don't know how to HUP:
  #service openstack-heat-api restart
  <134>Apr 11 14:06:22 node-3 heat-heat.api INFO: Starting Heat ReST API on 
0.0.0.0:8004
  <134>Apr 11 14:06:22 node-3 heat-eventlet.wsgi.server INFO: Starting single 
process server

  2.c) HUPing heat-engine is OK
  #pid=$(cat /var/run/heat/openstack-heat-engine.pid); kill -HUP $pid && echo 
$pid
  16512
  <134>Apr 11 14:12:15 node-3 heat-heat.openstack.common.service INFO: Caught 
SIGHUP, exiting
  <132>Apr 11 14:12:15 node-3 heat-heat.openstack.common.service WARNING: 
SIGHUP is supported: True
  <134>Apr 11 14:12:15 node-3 heat-heat.openstack.common.rpc.common INFO: 
Connected to AMQP server on ...
  service openstack-heat-engine status
  openstack-heat-engine (pid  16512) is running...

  2.d) HUPed heat-api is dead now ;(
  #kill -HUP $(cat /var/run/heat/openstack-heat-api.pid)
  (no new logs)
  # service openstack-heat-api status
  openstack-heat-api dead but pid file exists

  3)
  nova-cert, nova-novncproxy, nova-objectstore, nova-consoleauth, 
nova-scheduler - unlike to case 2, after kill -HUP  command 
was issued, there would be a "Caught SIGHUP" message in the logs, BUT the 
associated service would have got dead anyway. Instead, the service should 
remain started and its main thread PID should not be changed (similar to the 
2.c case).

  So, looks like there are a lot of things still should be done to
  ensure POSIX standards abidance in Openstack :-)

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1276694/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1530070] [NEW] Neutron Netns Cleanup script fails to delete namespaces after reboot

[Liaz Kamper]

Public bug reported:

After rebooting a node which held an active VRRP router, DHCP , and metadata 
agent, the neutron-netns-cleanup utility failed to delete stale namespaces. 
The utility fails with :

seting the network namespace "qrouter-3d4e5634-59f0-401e-
9f28-6c8daaec311c" failed: Invalid argument

The reason is a bug in iproute which fails to do any operation on a stale 
namespaces which appear in /var/run/netns like this:
root@stratonode66 ~# ls -l /var/run/netns/ 
total 0
rrr- 1 root root 0 Dec 24 13:38 qdhcp-0a348422-97e2-4ab6-bb22-55994a125823
rrr- 1 root root 0 Dec 24 11:54 qdhcp-2258aa3f-d256-4c9f-9e48-16811fc57981
rrr- 1 root root 0 Dec 24 13:38 qdhcp-3ceb1f27-e3fc-413a-a184-567041f073e2
rrr- 1 root root 0 Dec 24 11:54 qdhcp-62a51b66-d0e2-42fc-bdf2-2d622a889e75
rrr- 1 root root 0 Dec 24 11:54 qdhcp-81b550a2-c483-4280-a83a-b560ecdc416b
-- 1 root root 0 Dec 23 13:54 
qrouter-3d4e5634-59f0-401e-9f28-6c8daaec311c
-- 1 root root 0 Dec 24 11:25 
qrouter-69d20923-da78-4c6b-bb24-967dd67acb1d
-- 1 root root 0 Dec 23 13:54 
qrouter-cc649801-96ec-4d59-90de-1004fc026024

This bug s related, but doesn't solve the issue after reboot:
https://bugs.launchpad.net/neutron/+bug/1052535.

I solved it by fixing the neutron-netns-cleanup --force code, with this
patch:

diff --git a/neutron/agent/netns_cleanup_util.py 
b/neutron/agent/netns_cleanup_util.py
index 771a77f..3c43480 100644
--- a/neutron/agent/netns_cleanup_util.py
+++ b/neutron/agent/netns_cleanup_util.py
@@ -132,8 +132,13 @@ def destroy_namespace(conf, namespace, force=False):
 # NOTE: The dhcp driver will remove the namespace if is it empty,
 # so a second check is required here.
 if ip.netns.exists(namespace):
-for device in ip.get_devices(exclude_loopback=True):
-unplug_device(conf, device)
+try:
+for device in ip.get_devices(exclude_loopback=True):
+unplug_device(conf, device)
+except RuntimeError:
+LOG.info(_('Keep calm, and destroy namespace: %s'), 
namespace)
+ip.netns.delete(namespace)
+return
 
 ip.garbage_collect_namespace()
 except Exception:

When I run the following after reboot, the name spaces are cleaned-up
and when starting neutron-openvswitch-agent.service neutron-dhcp-
agent.service neutron-l3-agent.service they are recreated.

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1530070

Title:
  Neutron Netns Cleanup script fails to delete namespaces after reboot

Status in neutron:
  New

Bug description:
  After rebooting a node which held an active VRRP router, DHCP , and metadata 
agent, the neutron-netns-cleanup utility failed to delete stale namespaces. 
  The utility fails with :

  seting the network namespace "qrouter-3d4e5634-59f0-401e-
  9f28-6c8daaec311c" failed: Invalid argument

  The reason is a bug in iproute which fails to do any operation on a stale 
namespaces which appear in /var/run/netns like this:
  root@stratonode66 ~# ls -l /var/run/netns/ 
  total 0
  rrr- 1 root root 0 Dec 24 13:38 qdhcp-0a348422-97e2-4ab6-bb22-55994a125823
  rrr- 1 root root 0 Dec 24 11:54 qdhcp-2258aa3f-d256-4c9f-9e48-16811fc57981
  rrr- 1 root root 0 Dec 24 13:38 qdhcp-3ceb1f27-e3fc-413a-a184-567041f073e2
  rrr- 1 root root 0 Dec 24 11:54 qdhcp-62a51b66-d0e2-42fc-bdf2-2d622a889e75
  rrr- 1 root root 0 Dec 24 11:54 qdhcp-81b550a2-c483-4280-a83a-b560ecdc416b
  -- 1 root root 0 Dec 23 13:54 
qrouter-3d4e5634-59f0-401e-9f28-6c8daaec311c
  -- 1 root root 0 Dec 24 11:25 
qrouter-69d20923-da78-4c6b-bb24-967dd67acb1d
  -- 1 root root 0 Dec 23 13:54 
qrouter-cc649801-96ec-4d59-90de-1004fc026024

  This bug s related, but doesn't solve the issue after reboot:
  https://bugs.launchpad.net/neutron/+bug/1052535.

  I solved it by fixing the neutron-netns-cleanup --force code, with
  this patch:

  diff --git a/neutron/agent/netns_cleanup_util.py 
b/neutron/agent/netns_cleanup_util.py
  index 771a77f..3c43480 100644
  --- a/neutron/agent/netns_cleanup_util.py
  +++ b/neutron/agent/netns_cleanup_util.py
  @@ -132,8 +132,13 @@ def destroy_namespace(conf, namespace, force=False):
   # NOTE: The dhcp driver will remove the namespace if is it empty,
   # so a second check is required here.
   if ip.netns.exists(namespace):
  -for device in ip.get_devices(exclude_loopback=True):
  -unplug_device(conf, device)
  +try:
  +for device in ip.get_devices(exclude_loopback=True):
  +unplug_device(conf, device)
  +except RuntimeError:
  +LOG.info(_('Keep calm, and destroy 

[Yahoo-eng-team] [Bug 1467589] Re: Remove Cinder V1 support

[Yaguang Tang]

Even though we fix this issue in  devstack and openstackclient , there
are still some cases where devstack is using Cinder v1 API, this is duo
to os-config-client's default config file is using v1 api endpoint.
openstackclient get the cloud endpoint through os-config-client. Please
take a look at this fix  https://review.openstack.org/#/c/261787/

** Also affects: os-client-config
   Importance: Undecided
   Status: New

** Changed in: os-client-config
 Assignee: (unassigned) => Yaguang Tang (heut2008)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1467589

Title:
  Remove Cinder V1 support

Status in Cinder:
  Won't Fix
Status in devstack:
  In Progress
Status in grenade:
  In Progress
Status in heat:
  Confirmed
Status in OpenStack Compute (nova):
  In Progress
Status in os-client-config:
  New
Status in python-openstackclient:
  Fix Released
Status in Rally:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  Cinder created v2 support in the Grizzly release. This is to track
  progress in removing v1 support in other projects.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1467589/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1495862] Re: admin image table have no tenant_name when UpdateRow

[OpenStack Infra]

Reviewed:  https://review.openstack.org/223554
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=cc84199c8798d66fb910a5edb4e4497c8f27b2ca
Submitter: Jenkins
Branch:master

commit cc84199c8798d66fb910a5edb4e4497c8f27b2ca
Author: zhu.rong 
Date:   Tue Sep 15 20:03:47 2015 +0800

Fix no tenant name in admin image panel when UpdateRow

Steps for reproduce:
Login to Horizon as an admin user
Navigate to Admin--System--Images
Click the Create Image button, upload a large image from a HTTP URL
then will see the uploading image's project name is null.

Co-Authored-By:zhangguoqing

Change-Id: If10c3eb1bb5fa67c363ce9c6c514e2cd018de073
Closes-Bug: #1495862


** Changed in: horizon
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1495862

Title:
  admin image table have no tenant_name when UpdateRow

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Admin Images table when the image have UpdateRow action, it will give the 
message:
  The attribute tenant_name doesn't exist on 

  Steps for reproduce:
  Login to Horizon as an admin user
  Navigate to Admin--System--Images
  Click the Create Image button, upload a large image from a HTTP URL
  then will see the uploading image's project name is null.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1495862/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1529913] Re: use warning to avoid DeprecationWarning

[LiuNanke]

** Also affects: horizon
   Importance: Undecided
   Status: New

** Changed in: horizon
 Assignee: (unassigned) => LiuNanke (nanke-liu)

** Changed in: horizon
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1529913

Title:
  use warning to avoid DeprecationWarning

Status in Glance:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  New
Status in Manila:
  New
Status in OpenStack Compute (nova):
  New

Bug description:
  Python 3 deprecated the logger.warn method, see:

  https://docs.python.org/3/library/logging.html#logging.warning

  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1529913/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1529913] Re: use warning to avoid DeprecationWarning

[Ankit Agrawal]

** Also affects: keystone
   Importance: Undecided
   Status: New

** Changed in: keystone
 Assignee: (unassigned) => Ankit Agrawal (ankitagrawal)

** Also affects: nova
   Importance: Undecided
   Status: New

** Also affects: manila
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1529913

Title:
  use warning to avoid DeprecationWarning

Status in Glance:
  In Progress
Status in OpenStack Identity (keystone):
  New
Status in Manila:
  New
Status in OpenStack Compute (nova):
  New

Bug description:
  Python 3 deprecated the logger.warn method, see:

  https://docs.python.org/3/library/logging.html#logging.warning

  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1529913/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1529215] Re: "Description" form is not a textarea in Create or Update Image dialog

[OpenStack Infra]

Reviewed:  https://review.openstack.org/261468
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=307b2af8ac26177b7c92182f50b00efc4164786b
Submitter: Jenkins
Branch:master

commit 307b2af8ac26177b7c92182f50b00efc4164786b
Author: kenji-ishii 
Date:   Wed Dec 23 12:57:30 2015 +0900

Modify description form in Create or Update Image dialog

In Create or Update Image dialog, there have "description" form.
Currently it is not a textarea but it should be a textarea.

Change-Id: I80bb9e6ea784fb51609613a3a5868943cb086644
Closes-bug: #1529215


** Changed in: horizon
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1529215

Title:
  "Description" form is not a textarea in Create or Update Image dialog

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  In Create or Update Image dialog, there have "description" form. 
  Currently it is not a textarea but it should be a textarea.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1529215/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1530091] [NEW] check for mandatory parameter 'size' in schema/volumes.py missing for create

[Piyush Pathak]

Public bug reported:

1. Version of NOVA 12.0.1
2.  NA
3. 
   a). Try to Create volume without giving size as input parameter.
   b). Request failed.
   c). Response body have message---"message": "Invalid input received: Invalid 
input received: Volume size 'None' must be an integer and  greater than 0 (HTTP 
400)- Unexpected.
d). Error message is not clear.

Expected Result:
5. Error message should be  "'size' is a required property" it will give clear 
understanding that you cant skip the size parameter.

** Affects: nova
 Importance: Undecided
 Assignee: Piyush Pathak (cyperxprt)
 Status: New


** Tags: compute

** Changed in: nova
 Assignee: (unassigned) => Piyush Pathak (cyperxprt)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1530091

Title:
  check for mandatory parameter 'size' in schema/volumes.py missing for
  create

Status in OpenStack Compute (nova):
  New

Bug description:
  1. Version of NOVA 12.0.1
  2.  NA
  3. 
 a). Try to Create volume without giving size as input parameter.
 b). Request failed.
 c). Response body have message---"message": "Invalid input received: 
Invalid input received: Volume size 'None' must be an integer and  greater than 
0 (HTTP 400)- Unexpected.
  d). Error message is not clear.

  Expected Result:
  5. Error message should be  "'size' is a required property" it will give 
clear understanding that you cant skip the size parameter.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1530091/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1290234] Re: do not use __builtin__ in Python3

[Shuquan Huang]

** Also affects: magnum
   Importance: Undecided
   Status: New

** Changed in: magnum
 Assignee: (unassigned) => Shuquan Huang (shuquan)

** Also affects: octavia
   Importance: Undecided
   Status: New

** Changed in: octavia
 Assignee: (unassigned) => Shuquan Huang (shuquan)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1290234

Title:
  do not use __builtin__ in Python3

Status in Bandit:
  In Progress
Status in Glance:
  Fix Released
Status in heat:
  Triaged
Status in Ironic:
  Fix Released
Status in Magnum:
  In Progress
Status in neutron:
  In Progress
Status in octavia:
  In Progress
Status in Trove:
  In Progress
Status in tuskar:
  Fix Released

Bug description:
  __builtin__ does not exist in Python 3, use six.moves.builtins
  instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/bandit/+bug/1290234/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1290234] Re: do not use __builtin__ in Python3

[Abhishek Kekane]

** Also affects: nova
   Importance: Undecided
   Status: New

** Changed in: nova
 Assignee: (unassigned) => Abhishek Kekane (abhishek-kekane)

** Also affects: keystone
   Importance: Undecided
   Status: New

** Changed in: keystone
 Assignee: (unassigned) => Abhishek Kekane (abhishek-kekane)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1290234

Title:
  do not use __builtin__ in Python3

Status in Bandit:
  In Progress
Status in Glance:
  Fix Released
Status in heat:
  Triaged
Status in Ironic:
  Fix Released
Status in OpenStack Identity (keystone):
  New
Status in Magnum:
  In Progress
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  New
Status in octavia:
  In Progress
Status in Trove:
  In Progress
Status in tuskar:
  Fix Released

Bug description:
  __builtin__ does not exist in Python 3, use six.moves.builtins
  instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/bandit/+bug/1290234/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1529836] Re: Fix deprecated library function (os.popen()).

[Abhishek Kekane]

** Also affects: manila
   Importance: Undecided
   Status: New

** Changed in: manila
 Assignee: (unassigned) => Abhishek Kekane (abhishek-kekane)

** Also affects: cinder
   Importance: Undecided
   Status: New

** Changed in: cinder
 Assignee: (unassigned) => Abhishek Kekane (abhishek-kekane)

** Also affects: keystone
   Importance: Undecided
   Status: New

** Changed in: keystone
 Assignee: (unassigned) => Abhishek Kekane (abhishek-kekane)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1529836

Title:
  Fix deprecated library function (os.popen()).

Status in Cinder:
  New
Status in devstack:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  New
Status in Manila:
  New
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in oslo-incubator:
  In Progress
Status in OpenStack Object Storage (swift):
  In Progress
Status in tempest:
  In Progress

Bug description:
  Deprecated library function os.popen is still in use at some places.
  Need to replace it using subprocess module.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1529836/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1529913] Re: use warning to avoid DeprecationWarning

[LiuNanke]

** No longer affects: horizon

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1529913

Title:
  use warning to avoid DeprecationWarning

Status in Glance:
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in Manila:
  New
Status in OpenStack Compute (nova):
  New

Bug description:
  Python 3 deprecated the logger.warn method, see:

  https://docs.python.org/3/library/logging.html#logging.warning

  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1529913/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1290234] Re: do not use __builtin__ in Python3

[Shuquan Huang]

** Also affects: bandit
   Importance: Undecided
   Status: New

** Changed in: bandit
 Assignee: (unassigned) => Shuquan Huang (shuquan)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1290234

Title:
  do not use __builtin__ in Python3

Status in Bandit:
  In Progress
Status in Glance:
  Fix Released
Status in heat:
  Triaged
Status in Ironic:
  Fix Released
Status in neutron:
  In Progress
Status in Trove:
  In Progress
Status in tuskar:
  Fix Released

Bug description:
  __builtin__ does not exist in Python 3, use six.moves.builtins
  instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/bandit/+bug/1290234/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()

[Shuquan Huang]

** Also affects: ironic-python-agent
   Importance: Undecided
   Status: New

** Changed in: ironic-python-agent
 Assignee: (unassigned) => Shuquan Huang (shuquan)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1268480

Title:
  assertTrue(isinstance()) in tests should be replace with
  assertIsInstance()

Status in Ceilometer:
  Fix Released
Status in Cinder:
  Opinion
Status in Glance:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Invalid
Status in OpenStack Compute (nova):
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in tempest:
  New

Bug description:
  some of tests use different method of assertTrue(isinstance(A, B)) or
  assertEqual(type(A), B). The correct way is to use assertIsInstance(A,
  B) provided by testtools

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1268480/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1529913] Re: use warning to avoid DeprecationWarning

[LiuNanke]

** Also affects: horizon
   Importance: Undecided
   Status: New

** Changed in: horizon
 Assignee: (unassigned) => LiuNanke (nanke-liu)

** Changed in: horizon
   Status: New => In Progress

** Also affects: trove
   Importance: Undecided
   Status: New

** Changed in: trove
 Assignee: (unassigned) => LiuNanke (nanke-liu)

** Changed in: trove
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1529913

Title:
  use warning to avoid DeprecationWarning

Status in Glance:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in Manila:
  New
Status in OpenStack Compute (nova):
  In Progress
Status in Trove:
  In Progress

Bug description:
  Python 3 deprecated the logger.warn method, see:

  https://docs.python.org/3/library/logging.html#logging.warning

  so we prefer to use warning to avoid DeprecationWarning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1529913/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()

[Shuquan Huang]

** Also affects: tempest
   Importance: Undecided
   Status: New

** Changed in: tempest
 Assignee: (unassigned) => Shuquan Huang (shuquan)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1268480

Title:
  assertTrue(isinstance()) in tests should be replace with
  assertIsInstance()

Status in Ceilometer:
  Fix Released
Status in Cinder:
  Opinion
Status in Glance:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Invalid
Status in OpenStack Compute (nova):
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  some of tests use different method of assertTrue(isinstance(A, B)) or
  assertEqual(type(A), B). The correct way is to use assertIsInstance(A,
  B) provided by testtools

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1268480/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1529534] Re: User new log style where Logger.exception() is used by passing an exception object as the first argument.

[LiuNanke]

** Also affects: cinder
   Importance: Undecided
   Status: New

** Changed in: cinder
   Status: New => In Progress

** Changed in: cinder
 Assignee: (unassigned) => LiuNanke (nanke-liu)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1529534

Title:
  User new log style where Logger.exception() is used by passing an
  exception object as the first argument.

Status in Ceilometer:
  New
Status in Cinder:
  In Progress
Status in Gnocchi:
  In Progress
Status in Ironic:
  In Progress
Status in Magnum:
  In Progress
Status in Manila:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in python-ceilometerclient:
  New
Status in python-glanceclient:
  New
Status in python-gnocchiclient:
  In Progress
Status in python-keystoneclient:
  New
Status in python-neutronclient:
  Confirmed
Status in python-troveclient:
  New
Status in Sahara:
  New
Status in Trove:
  New

Bug description:
  Use new log style where Logger.exception() is used by passing an
  exception object as the first argument[1].

  [1]http://docs.openstack.org/developer/oslo.log/usage.html#no-more-
  implicit-conversion-to-unicode-str

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1529534/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()

[Shuquan Huang]

** Also affects: barbican
   Importance: Undecided
   Status: New

** Changed in: barbican
 Assignee: (unassigned) => Shuquan Huang (shuquan)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1268480

Title:
  assertTrue(isinstance()) in tests should be replace with
  assertIsInstance()

Status in Barbican:
  In Progress
Status in Ceilometer:
  Fix Released
Status in Cinder:
  Opinion
Status in CloudRoast:
  New
Status in Glance:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Invalid
Status in OpenStack Compute (nova):
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  some of tests use different method of assertTrue(isinstance(A, B)) or
  assertEqual(type(A), B). The correct way is to use assertIsInstance(A,
  B) provided by testtools

To manage notifications about this bug go to:
https://bugs.launchpad.net/barbican/+bug/1268480/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()

[Shuquan Huang]

** Also affects: cloudroast
   Importance: Undecided
   Status: New

** Changed in: cloudroast
 Assignee: (unassigned) => Shuquan Huang (shuquan)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1268480

Title:
  assertTrue(isinstance()) in tests should be replace with
  assertIsInstance()

Status in Barbican:
  In Progress
Status in Ceilometer:
  Fix Released
Status in Cinder:
  In Progress
Status in CloudRoast:
  New
Status in Glance:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Invalid
Status in OpenStack Compute (nova):
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  some of tests use different method of assertTrue(isinstance(A, B)) or
  assertEqual(type(A), B). The correct way is to use assertIsInstance(A,
  B) provided by testtools

To manage notifications about this bug go to:
https://bugs.launchpad.net/barbican/+bug/1268480/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()

[OpenStack Infra]

Fix proposed to branch: master
Review: https://review.openstack.org/262540

** Changed in: cinder
   Status: Opinion => In Progress

** Changed in: cinder
 Assignee: Liusheng (liusheng) => Shuquan Huang (shuquan)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1268480

Title:
  assertTrue(isinstance()) in tests should be replace with
  assertIsInstance()

Status in Barbican:
  In Progress
Status in Ceilometer:
  Fix Released
Status in Cinder:
  In Progress
Status in CloudRoast:
  New
Status in Glance:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Invalid
Status in OpenStack Compute (nova):
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  some of tests use different method of assertTrue(isinstance(A, B)) or
  assertEqual(type(A), B). The correct way is to use assertIsInstance(A,
  B) provided by testtools

To manage notifications about this bug go to:
https://bugs.launchpad.net/barbican/+bug/1268480/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp