[Yahoo-eng-team] [Bug 1526413] [NEW] test_app_using_ipv6_and_ssl fails with requests 2.9.0

2015-12-15 Thread Matt Riedemann
Public bug reported:

http://logs.openstack.org/50/257950/1/check/gate-nova-
python27/6dfe685/testr_results.html.gz

ft1.13019: 
nova.tests.unit.test_wsgi.TestWSGIServerWithSSL.test_app_using_ipv6_and_ssl_StringException:
 Empty attachments:
  stdout

pythonlogging:'': {{{
2015-12-15 15:55:06,381 WARNING [oslo_reports.guru_meditation_report] Guru 
mediation now registers SIGUSR1 and SIGUSR2 by default for backward 
compatibility. SIGUSR1 will no longer be registered in a future release, so 
please use SIGUSR2 to generate reports.
2015-12-15 15:55:06,383 INFO [nova.wsgi] fake_ssl listening on ::1:54837
2015-12-15 15:55:06,390 INFO [nova.fake_ssl.wsgi.server] (6121) wsgi starting 
up on https://::1:54837/
}}}

stderr: {{{
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:315:
 SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name 
Indication) extension to TLS is not available on this platform. This may cause 
the server to present an incorrect TLS certificate, which can cause validation 
failures. For more information, see 
https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning.
  SNIMissingWarning
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:120:
 InsecurePlatformWarning: A true SSLContext object is not available. This 
prevents urllib3 from configuring SSL appropriately and may cause certain SSL 
connections to fail. For more information, see 
https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
}}}

Traceback (most recent call last):
  File "nova/tests/unit/test_wsgi.py", line 333, in test_app_using_ipv6_and_ssl
verify=os.path.join(SSL_CERT_DIR, 'ca.crt'))
  File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/api.py",
 line 67, in get
return request('get', url, params=params, **kwargs)
  File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/api.py",
 line 53, in request
return session.request(method=method, url=url, **kwargs)
  File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/sessions.py",
 line 468, in request
resp = self.send(prep, **send_kwargs)
  File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/sessions.py",
 line 576, in send
r = adapter.send(request, **kwargs)
  File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/adapters.py",
 line 447, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: hostname '[::1]' doesn't match either of 
'localhost', 'ip6-localhost', '127.0.0.1', '::1'

http://logstash.openstack.org/#dashboard/file/logstash.json?query=message:%5C%22requests.exceptions.SSLError:%20hostname%20'%5B::1%5D'%20doesn't%20match%20either%20of%20'localhost',%20'ip6-localhost',%20'127.0.0.1',%20'::1'%5C%22%20AND%20tags:%5C%22console%5C%22

just started today when requests 2.9.0 was released:

https://pypi.python.org/pypi/requests/2.9.0

** Affects: nova
 Importance: Critical
 Status: Confirmed


** Tags: api testing

** Changed in: nova
   Status: New => Confirmed

** Changed in: nova
   Importance: Undecided => Critical

-- 
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/1526413

Title:
  test_app_using_ipv6_and_ssl fails with requests 2.9.0

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  http://logs.openstack.org/50/257950/1/check/gate-nova-
  python27/6dfe685/testr_results.html.gz

  ft1.13019: 
nova.tests.unit.test_wsgi.TestWSGIServerWithSSL.test_app_using_ipv6_and_ssl_StringException:
 Empty attachments:
stdout

  pythonlogging:'': {{{
  2015-12-15 15:55:06,381 WARNING [oslo_reports.guru_meditation_report] Guru 
mediation now registers SIGUSR1 and SIGUSR2 by default for backward 
compatibility. SIGUSR1 will no longer be registered in a future release, so 
please use SIGUSR2 to generate reports.
  2015-12-15 15:55:06,383 INFO [nova.wsgi] fake_ssl listening on ::1:54837
  2015-12-15 15:55:06,390 INFO [nova.fake_ssl.wsgi.server] (6121) wsgi starting 
up on https://::1:54837/
  }}}

  stderr: {{{
  
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:315:
 SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name 
Indication) extension to TLS is not available on this platform. This may cause 
the server to present an incorrect TLS certificate, which can cause validation 
failures. For more information, see 
https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning.
SNIMissingWarning

[Yahoo-eng-team] [Bug 1526462] [NEW] Need support for OpenDirectory in LDAP driver

2015-12-15 Thread Andrey Grebennikov
Public bug reported:

It is necessary to support Apple OpenDirectory as the backend for
Keystone Identity.

OpenDirectory uses a concept of POSIX groups, when the entities of users
in the groups are represented as UIDs, not full DNs:

dn: cn=group1, cn=groups,dc=domain,dc=com

memberUid: user1
memberUid: user2


while in the driver of LDAP it is hardcoded that the entities could be
only full DNs, like:

dn: cn=group1, cn=groups,dc=domain,dc=com

memberUid: uid=user1,cn=users,dc=domain,dc=com
memberUid: uid=user2,cn=users,dc=domain,dc=com

Because of this reason it is impossible to use groups in Keystone and we
cannot assign the roles to the Keystone groups - Keystone doesn't
recognize any user to be a part of any group. When it checks the roles,
it searches for the direct user's assignments, and then for any groups
which the user can be a member of. So by default the search returns
nothing.

We have to have an additional parameter in the config where we specify
the type of the entity in the groups - whether is it currently a dn or
an id.

** Affects: keystone
 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/1526462

Title:
  Need support for OpenDirectory in LDAP driver

Status in OpenStack Identity (keystone):
  New

Bug description:
  It is necessary to support Apple OpenDirectory as the backend for
  Keystone Identity.

  OpenDirectory uses a concept of POSIX groups, when the entities of
  users in the groups are represented as UIDs, not full DNs:

  dn: cn=group1, cn=groups,dc=domain,dc=com
  
  memberUid: user1
  memberUid: user2
  

  while in the driver of LDAP it is hardcoded that the entities could be
  only full DNs, like:

  dn: cn=group1, cn=groups,dc=domain,dc=com
  
  memberUid: uid=user1,cn=users,dc=domain,dc=com
  memberUid: uid=user2,cn=users,dc=domain,dc=com

  Because of this reason it is impossible to use groups in Keystone and
  we cannot assign the roles to the Keystone groups - Keystone doesn't
  recognize any user to be a part of any group. When it checks the
  roles, it searches for the direct user's assignments, and then for any
  groups which the user can be a member of. So by default the search
  returns nothing.

  We have to have an additional parameter in the config where we specify
  the type of the entity in the groups - whether is it currently a dn or
  an id.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1526462/+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 1523357] Re: fwaas tempest tests are failing

2015-12-15 Thread YAMAMOTO Takashi
fixed in fwaas repo

** Changed in: networking-midonet
   Status: In Progress => Fix Released

** Changed in: networking-midonet
Milestone: None => 2.0.0

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

Title:
  fwaas tempest tests are failing

Status in networking-midonet:
  Fix Released
Status in neutron:
  Fix Released

Bug description:
  recently added fwaas tests are failing in 
gate-tempest-dsvm-networking-midonet-v2 job.
  eg. test_firewall_admin_disable

  http://logs.openstack.org/87/199387/8/check/gate-tempest-dsvm-
  networking-midonet-v2/3fb3f3b/logs/testr_results.html.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-midonet/+bug/1523357/+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 1526137] Re: when upgrade openstack-dashboard many times, httpd service start failed

2015-12-15 Thread Stefano Maffulli
** Project changed: openstack-community => horizon

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

Title:
  when upgrade openstack-dashboard many times, httpd service start
  failed

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  there is a bug in post script of openstack-horizon.spec  :

  %post -n openstack-dashboard
  # ugly hack to set a unique SECRET_KEY
  sed -i "/^from horizon.utils import secret_key$/d" 
/etc/openstack-dashboard/local_settings
  sed -i "/^SECRET_KEY.*$/{N;s/^.*$/SECRET_KEY='`openssl rand -hex 10`'/}" 
/etc/openstack-dashboard/local_settings

  When upgrading dashboard rpm,  SECRET_KEY in /etc/openstack-
  dashboard/local_settings will be updated, and it will be swallow a
  line of the config file  at the same time.  so after upgrding
  openstack-dashboard for twelve times, the line of "CACHES = {" will be
  deleted, and the bug happened.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1526137/+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 1526137] [NEW] when upgrade openstack-dashboard many times, httpd service start failed

2015-12-15 Thread Launchpad Bug Tracker
You have been subscribed to a public bug:

there is a bug in post script of openstack-horizon.spec  :

%post -n openstack-dashboard
# ugly hack to set a unique SECRET_KEY
sed -i "/^from horizon.utils import secret_key$/d" 
/etc/openstack-dashboard/local_settings
sed -i "/^SECRET_KEY.*$/{N;s/^.*$/SECRET_KEY='`openssl rand -hex 10`'/}" 
/etc/openstack-dashboard/local_settings

When upgrading dashboard rpm,  SECRET_KEY in /etc/openstack-
dashboard/local_settings will be updated, and it will be swallow a line
of the config file  at the same time.  so after upgrding openstack-
dashboard for twelve times, the line of "CACHES = {" will be deleted,
and the bug happened.

** Affects: horizon
 Importance: Undecided
 Status: New

-- 
when upgrade openstack-dashboard many times, httpd service start failed
https://bugs.launchpad.net/bugs/1526137
You received this bug notification because you are a member of Yahoo! 
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).

-- 
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 1526413] Re: test_app_using_ipv6_and_ssl fails with requests 2.9.0

2015-12-15 Thread Matt Riedemann
** Also affects: nova/liberty
   Importance: Undecided
   Status: New

** Changed in: nova/liberty
   Status: New => Confirmed

** Changed in: nova/liberty
   Importance: Undecided => High

-- 
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/1526413

Title:
  test_app_using_ipv6_and_ssl fails with requests 2.9.0

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) liberty series:
  Confirmed

Bug description:
  http://logs.openstack.org/50/257950/1/check/gate-nova-
  python27/6dfe685/testr_results.html.gz

  ft1.13019: 
nova.tests.unit.test_wsgi.TestWSGIServerWithSSL.test_app_using_ipv6_and_ssl_StringException:
 Empty attachments:
stdout

  pythonlogging:'': {{{
  2015-12-15 15:55:06,381 WARNING [oslo_reports.guru_meditation_report] Guru 
mediation now registers SIGUSR1 and SIGUSR2 by default for backward 
compatibility. SIGUSR1 will no longer be registered in a future release, so 
please use SIGUSR2 to generate reports.
  2015-12-15 15:55:06,383 INFO [nova.wsgi] fake_ssl listening on ::1:54837
  2015-12-15 15:55:06,390 INFO [nova.fake_ssl.wsgi.server] (6121) wsgi starting 
up on https://::1:54837/
  }}}

  stderr: {{{
  
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:315:
 SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name 
Indication) extension to TLS is not available on this platform. This may cause 
the server to present an incorrect TLS certificate, which can cause validation 
failures. For more information, see 
https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning.
SNIMissingWarning
  
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:120:
 InsecurePlatformWarning: A true SSLContext object is not available. This 
prevents urllib3 from configuring SSL appropriately and may cause certain SSL 
connections to fail. For more information, see 
https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
InsecurePlatformWarning
  }}}

  Traceback (most recent call last):
File "nova/tests/unit/test_wsgi.py", line 333, in 
test_app_using_ipv6_and_ssl
  verify=os.path.join(SSL_CERT_DIR, 'ca.crt'))
File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/api.py",
 line 67, in get
  return request('get', url, params=params, **kwargs)
File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/api.py",
 line 53, in request
  return session.request(method=method, url=url, **kwargs)
File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/sessions.py",
 line 468, in request
  resp = self.send(prep, **send_kwargs)
File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/sessions.py",
 line 576, in send
  r = adapter.send(request, **kwargs)
File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/adapters.py",
 line 447, in send
  raise SSLError(e, request=request)
  requests.exceptions.SSLError: hostname '[::1]' doesn't match either of 
'localhost', 'ip6-localhost', '127.0.0.1', '::1'

  
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message:%5C%22requests.exceptions.SSLError:%20hostname%20'%5B::1%5D'%20doesn't%20match%20either%20of%20'localhost',%20'ip6-localhost',%20'127.0.0.1',%20'::1'%5C%22%20AND%20tags:%5C%22console%5C%22

  just started today when requests 2.9.0 was released:

  https://pypi.python.org/pypi/requests/2.9.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1526413/+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 1526446] Re: compute evacuate documentation doesn't match api behavior

2015-12-15 Thread Steve Martinelli
this shouldn't be affecting keystone, just the api-site, and
specifically nova APIs

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

-- 
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/1526446

Title:
  compute evacuate documentation doesn't match api behavior

Status in OpenStack Identity (keystone):
  Invalid
Status in openstack-api-site:
  New

Bug description:
  I am using OpenStack Liberty, installed using the ansible all-in-one
  deployment. The documentation for the evacuate command in the compute
  v2.1 API does not appear to match what I am seeing.

  http://developer.openstack.org/api-ref-compute-v2.1.html#evacuate

  1. The on_shared_storage attribute in the documentation should
  actually be onSharedStorage. When I use on_shared_storage, I get the
  following error message: "Invalid input for field/attribute evacuate.
  Value: {u'on_shared_storage': False}. Additional properties are not
  allowed (u'on_shared_storage' was unexpected)". When I leave the
  attribute off entirely, I get this error which lead me to the correct
  attribute name: "Invalid input for field/attribute evacuate. Value:
  {}. 'onSharedStorage' is a required property".

  2. The admin_password attribute in the documentation does not appear
  to be a valid attribute at all. When I use admin_password, I get the
  following error message: "Invalid input for field/attribute evacuate.
  Value: {u'onSharedStorage': False, u'admin_password': u'top-secret-
  password'}. Additional properties are not allowed (u'admin_password'
  was unexpected)". I also tried adminPassword (see #1 as for why I
  thought that may work) but that was rejected with a similar error
  message.

  Here is the response from the compute versions endpoint, in case that
  helps narrow down which version I am using. I am not sending a
  microversion header.

  {
"versions": [
  {
"status": "SUPPORTED",
"updated": "2011-01-21T11:33:21Z",
"links": [
  {
"href": "http://104.130.30.68:8774/v2/;,
"rel": "self"
  }
],
"min_version": "",
"version": "",
"id": "v2.0"
  },
  {
"status": "CURRENT",
"updated": "2013-07-23T11:33:21Z",
"links": [
  {
"href": "http://104.130.30.68:8774/v2.1/;,
"rel": "self"
  }
],
"min_version": "2.1",
"version": "2.12",
"id": "v2.1"
  }
]
  }

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1526446/+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 1526413] Re: test_app_using_ipv6_and_ssl fails with requests 2.9.0

2015-12-15 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/258001
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=ba82e4a875f01bb883deb78517953989b690a36c
Submitter: Jenkins
Branch:master

commit ba82e4a875f01bb883deb78517953989b690a36c
Author: Matt Riedemann 
Date:   Tue Dec 15 08:38:17 2015 -0800

Block requests 2.9.0

Breaks the wsgi IPv6 unit tests.

Depends-On: Ifb080c72a16ed4b93040fb7c06bdc072b7247f6e

Change-Id: I158bd1cba9bc85521ac0e236f66e7780a59e9ac2
Closes-Bug: #1526413


** 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/1526413

Title:
  test_app_using_ipv6_and_ssl fails with requests 2.9.0

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  http://logs.openstack.org/50/257950/1/check/gate-nova-
  python27/6dfe685/testr_results.html.gz

  ft1.13019: 
nova.tests.unit.test_wsgi.TestWSGIServerWithSSL.test_app_using_ipv6_and_ssl_StringException:
 Empty attachments:
stdout

  pythonlogging:'': {{{
  2015-12-15 15:55:06,381 WARNING [oslo_reports.guru_meditation_report] Guru 
mediation now registers SIGUSR1 and SIGUSR2 by default for backward 
compatibility. SIGUSR1 will no longer be registered in a future release, so 
please use SIGUSR2 to generate reports.
  2015-12-15 15:55:06,383 INFO [nova.wsgi] fake_ssl listening on ::1:54837
  2015-12-15 15:55:06,390 INFO [nova.fake_ssl.wsgi.server] (6121) wsgi starting 
up on https://::1:54837/
  }}}

  stderr: {{{
  
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:315:
 SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name 
Indication) extension to TLS is not available on this platform. This may cause 
the server to present an incorrect TLS certificate, which can cause validation 
failures. For more information, see 
https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning.
SNIMissingWarning
  
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:120:
 InsecurePlatformWarning: A true SSLContext object is not available. This 
prevents urllib3 from configuring SSL appropriately and may cause certain SSL 
connections to fail. For more information, see 
https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
InsecurePlatformWarning
  }}}

  Traceback (most recent call last):
File "nova/tests/unit/test_wsgi.py", line 333, in 
test_app_using_ipv6_and_ssl
  verify=os.path.join(SSL_CERT_DIR, 'ca.crt'))
File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/api.py",
 line 67, in get
  return request('get', url, params=params, **kwargs)
File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/api.py",
 line 53, in request
  return session.request(method=method, url=url, **kwargs)
File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/sessions.py",
 line 468, in request
  resp = self.send(prep, **send_kwargs)
File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/sessions.py",
 line 576, in send
  r = adapter.send(request, **kwargs)
File 
"/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/adapters.py",
 line 447, in send
  raise SSLError(e, request=request)
  requests.exceptions.SSLError: hostname '[::1]' doesn't match either of 
'localhost', 'ip6-localhost', '127.0.0.1', '::1'

  
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message:%5C%22requests.exceptions.SSLError:%20hostname%20'%5B::1%5D'%20doesn't%20match%20either%20of%20'localhost',%20'ip6-localhost',%20'127.0.0.1',%20'::1'%5C%22%20AND%20tags:%5C%22console%5C%22

  just started today when requests 2.9.0 was released:

  https://pypi.python.org/pypi/requests/2.9.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1526413/+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 1525279] Re: Request Liberty release for networking-bgpvpn

2015-12-15 Thread Kyle Mestery
This is now published to PyPI: https://pypi.python.org/pypi/networking-
bgpvpn/3.0.0

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

** Changed in: neutron
Milestone: None => mitaka-2

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

Title:
  Request Liberty release for networking-bgpvpn

Status in bgpvpn:
  New
Status in neutron:
  Fix Released

Bug description:
  The networking-bgpvpn project is now ready to have its first release.

  We'd like to create a dedicated branch to backport needed patches in
  the future.

  Release Info :

  Current branch : master
  Commit-Id : 157f73d3f248f1e1008e1e7f908dd616762325bc
  New Tag: 3.0.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/bgpvpn/+bug/1525279/+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 1522524] Re: User can delete deactivated images

2015-12-15 Thread Tristan Cacqueray
Until a clear consensus about whenever this bug caused an actual
security vulnerability, the OSSA task is now Won't Fix.

** Changed in: ossa
   Status: Confirmed => Won't Fix

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

Title:
  User can delete deactivated images

Status in Glance:
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  
  Overview:

  
  In glance once an admin has marked a image as deactivated a user can no 
longer download or delete that image. This is so an image can be inspected by 
the admins without the user interfering.
  However, these restrictions can be avoided specifically allowing a user to 
delete a deactivated image. Meaning an admin would not be able to guarantee the 
status of a deactivated image.

  What should happen: 403 What does happen: 200

  How to reproduce:
  1. Create an image.
  echo test | glance image-create --name 3 --container-format bare 
--disk-format raw

  2. Deactivate the image.
  glance image-deactivate 0630d5e4-6009-4723-94e6-1ad056ab649a

  3. Check image is deactivated.
  glance image-show 0630d5e4-6009-4723-94e6-1ad056ab649a

  4. Using the v1 API delete the image.
  curl -X DELETE 
http://localhost:9292/v1/images/0630d5e4-6009-4723-94e6-1ad056ab649a -H 
'X-Auth-token: 108322e43f6346ebadb3c2fb72831913'

  5. Image is now gone.
  glance image-show 0630d5e4-6009-4723-94e6-1ad056ab649a

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1522524/+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 1526446] [NEW] compute evacuate documentation doesn't match api behavior

2015-12-15 Thread Carolyn Van Slyck
Public bug reported:

I am using OpenStack Liberty, installed using the ansible all-in-one
deployment. The documentation for the evacuate command in the compute
v2.1 API does not appear to match what I am seeing.

http://developer.openstack.org/api-ref-compute-v2.1.html#evacuate

1. The on_shared_storage attribute in the documentation should actually
be onSharedStorage. When I use on_shared_storage, I get the following
error message: "Invalid input for field/attribute evacuate. Value:
{u'on_shared_storage': False}. Additional properties are not allowed
(u'on_shared_storage' was unexpected)". When I leave the attribute off
entirely, I get this error which lead me to the correct attribute name:
"Invalid input for field/attribute evacuate. Value: {}.
'onSharedStorage' is a required property".

2. The admin_password attribute in the documentation does not appear to
be a valid attribute at all. When I use admin_password, I get the
following error message: "Invalid input for field/attribute evacuate.
Value: {u'onSharedStorage': False, u'admin_password': u'top-secret-
password'}. Additional properties are not allowed (u'admin_password' was
unexpected)". I also tried adminPassword (see #1 as for why I thought
that may work) but that was rejected with a similar error message.

Here is the response from the compute versions endpoint, in case that
helps narrow down which version I am using. I am not sending a
microversion header.

{
  "versions": [
{
  "status": "SUPPORTED",
  "updated": "2011-01-21T11:33:21Z",
  "links": [
{
  "href": "http://104.130.30.68:8774/v2/;,
  "rel": "self"
}
  ],
  "min_version": "",
  "version": "",
  "id": "v2.0"
},
{
  "status": "CURRENT",
  "updated": "2013-07-23T11:33:21Z",
  "links": [
{
  "href": "http://104.130.30.68:8774/v2.1/;,
  "rel": "self"
}
  ],
  "min_version": "2.1",
  "version": "2.12",
  "id": "v2.1"
}
  ]
}

** Affects: keystone
 Importance: Undecided
 Status: New

** Affects: openstack-api-site
 Importance: Undecided
 Status: New

** Also affects: openstack-api-site
   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/1526446

Title:
  compute evacuate documentation doesn't match api behavior

Status in OpenStack Identity (keystone):
  New
Status in openstack-api-site:
  New

Bug description:
  I am using OpenStack Liberty, installed using the ansible all-in-one
  deployment. The documentation for the evacuate command in the compute
  v2.1 API does not appear to match what I am seeing.

  http://developer.openstack.org/api-ref-compute-v2.1.html#evacuate

  1. The on_shared_storage attribute in the documentation should
  actually be onSharedStorage. When I use on_shared_storage, I get the
  following error message: "Invalid input for field/attribute evacuate.
  Value: {u'on_shared_storage': False}. Additional properties are not
  allowed (u'on_shared_storage' was unexpected)". When I leave the
  attribute off entirely, I get this error which lead me to the correct
  attribute name: "Invalid input for field/attribute evacuate. Value:
  {}. 'onSharedStorage' is a required property".

  2. The admin_password attribute in the documentation does not appear
  to be a valid attribute at all. When I use admin_password, I get the
  following error message: "Invalid input for field/attribute evacuate.
  Value: {u'onSharedStorage': False, u'admin_password': u'top-secret-
  password'}. Additional properties are not allowed (u'admin_password'
  was unexpected)". I also tried adminPassword (see #1 as for why I
  thought that may work) but that was rejected with a similar error
  message.

  Here is the response from the compute versions endpoint, in case that
  helps narrow down which version I am using. I am not sending a
  microversion header.

  {
"versions": [
  {
"status": "SUPPORTED",
"updated": "2011-01-21T11:33:21Z",
"links": [
  {
"href": "http://104.130.30.68:8774/v2/;,
"rel": "self"
  }
],
"min_version": "",
"version": "",
"id": "v2.0"
  },
  {
"status": "CURRENT",
"updated": "2013-07-23T11:33:21Z",
"links": [
  {
"href": "http://104.130.30.68:8774/v2.1/;,
"rel": "self"
  }
],
"min_version": "2.1",
"version": "2.12",
"id": "v2.1"
  }
]
  }

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1526446/+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   : 

[Yahoo-eng-team] [Bug 1526436] [NEW] {RFE] Add support for VMware Edge appliance loadbalancer to neutron lbaas

2015-12-15 Thread Kobi Samoray
Public bug reported:

VMware NSX networking virtualization offers various networking functions with 
the build-in Edge appliances.
One of the features which the Edge appliance has is a built-in load balancer.
This load balancer is currently supported by an LBaaS v1 driver, but has no 
LBaaS v2 support.
Support for v2 is required before v1 deprecation.

** Affects: neutron
 Importance: Undecided
 Assignee: Kobi Samoray (ksamoray)
 Status: In Progress


** Tags: lbaas rfe

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

Title:
  {RFE] Add support for VMware Edge appliance loadbalancer to neutron
  lbaas

Status in neutron:
  In Progress

Bug description:
  VMware NSX networking virtualization offers various networking functions with 
the build-in Edge appliances.
  One of the features which the Edge appliance has is a built-in load balancer.
  This load balancer is currently supported by an LBaaS v1 driver, but has no 
LBaaS v2 support.
  Support for v2 is required before v1 deprecation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1526436/+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 1353939] Re: Rescue fails with 'Failed to terminate process: Device or resource busy' in the n-cpu log

2015-12-15 Thread Billy Olsen
This fix was made available in 1:2014.2.4-0ubuntu1~cloud4 of nova in the
Ubuntu Cloud Archive for Juno.

** Changed in: cloud-archive/juno
   Status: In Progress => Fix Committed

** Changed in: cloud-archive/juno
   Status: Fix Committed => Fix Released

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

Title:
  Rescue fails with 'Failed to terminate process: Device or resource
  busy' in the n-cpu log

Status in Ubuntu Cloud Archive:
  Invalid
Status in Ubuntu Cloud Archive juno series:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) juno series:
  New
Status in OpenStack Compute (nova) kilo series:
  Fix Released
Status in nova package in Ubuntu:
  Invalid

Bug description:
  [Impact]

   * Users may sometimes fail to shutdown an instance if the associated qemu
 process is on uninterruptable sleep (typically IO).

  [Test Case]

   * 1. create some IO load in a VM
 2. look at the associated qemu, make sure it has STAT D in ps output
 3. shutdown the instance
 4. with the patch in place, nova will retry calling libvirt to shutdown
the instance 3 times to wait for the signal to be delivered to the 
qemu process.

  [Regression Potential]

   * None


  message: "Failed to terminate process" AND
  message:'InstanceNotRescuable' AND message: 'Exception during message
  handling' AND tags:"screen-n-cpu.txt"

  The above log stash-query reports back only the failed jobs, the 'Failed to 
terminate process' close other failed rescue tests,
  but tempest does not always reports them as an error at the end.

  message: "Failed to terminate process" AND tags:"screen-n-cpu.txt"

  Usual console log:
  Details: (ServerRescueTestJSON:test_rescue_unrescue_instance) Server 
0573094d-53da-40a5-948a-747d181462f5 failed to reach RESCUE status and task 
state "None" within the required time (196 s). Current status: SHUTOFF. Current 
task state: None.

  http://logs.openstack.org/82/107982/2/gate/gate-tempest-dsvm-postgres-
  full/90726cb/console.html#_2014-08-07_03_50_26_520

  Usual n-cpu exception:
  
http://logs.openstack.org/82/107982/2/gate/gate-tempest-dsvm-postgres-full/90726cb/logs/screen-n-cpu.txt.gz#_2014-08-07_03_32_02_855

  2014-08-07 03:32:02.855 ERROR oslo.messaging.rpc.dispatcher 
[req-39ce7a3d-5ceb-41f5-8f9f-face7e608bd1 ServerRescueTestJSON-2035684545 
ServerRescueTestJSON-1017508309] Exception during message handling: Instance 
0573094d-53da-40a5-948a-747d181462f5 cannot be rescued: Driver Error: Failed to 
terminate process 26425 with SIGKILL: Device or resource busy
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher Traceback 
(most recent call last):
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher   File 
"/usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 
134, in _dispatch_and_reply
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher 
incoming.message))
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher   File 
"/usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 
177, in _dispatch
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return 
self._do_dispatch(endpoint, method, ctxt, args)
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher   File 
"/usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 
123, in _do_dispatch
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher result 
= getattr(endpoint, method)(ctxt, **new_args)
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher   File 
"/opt/stack/new/nova/nova/compute/manager.py", line 408, in decorated_function
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return 
function(self, context, *args, **kwargs)
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher   File 
"/opt/stack/new/nova/nova/exception.py", line 88, in wrapped
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher payload)
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher   File 
"/opt/stack/new/nova/nova/openstack/common/excutils.py", line 82, in __exit__
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher 
six.reraise(self.type_, self.value, self.tb)
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher   File 
"/opt/stack/new/nova/nova/exception.py", line 71, in wrapped
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return 
f(self, context, *args, **kw)
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher   File 
"/opt/stack/new/nova/nova/compute/manager.py", line 292, in decorated_function
  2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher pass
  2014-08-07 03:32:02.855 

[Yahoo-eng-team] [Bug 1524562] Re: No error raised if PUT/GET/PATCH/DELETE domain-specific driver configuration database store with an invalid domain id

2015-12-15 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/256889
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=5560c7060dcc906b07080c44511551c45172ecf0
Submitter: Jenkins
Branch:master

commit 5560c7060dcc906b07080c44511551c45172ecf0
Author: Thomas Hsiao 
Date:   Fri Dec 11 15:55:19 2015 -0800

Validate domain for DB-based domain config. CRUD

For CRUD of Identity API-based domain-specific driver configuration
in database store, if the client provides an invalid domain id,
the request shall be rejected with a response 404 domain not found.

Change-Id: I9e861d450da1a49d31bac08bea12a0e2e84c6476
Closes-Bug: 1524562


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

-- 
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/1524562

Title:
  No error raised if PUT/GET/PATCH/DELETE  domain-specific driver
  configuration database store with an invalid domain id

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  No error raised if PUT/GET/PATCH/DELETE sql-based domain driver
  configuration with a invalid domain id:

  For domain-specific driver configuration database store, Identity API creates 
the configuration options into the database even though the provided domain id 
is the the request url is invalid.
  For example, a user can create config options using an invalid domain id 
(123456789) as shown below:

  ~$ curl -s \
  >   -H "X-Auth-Token: ADMIN" \
  >   -H "Content-Type: application/json" \
  >   -d '
  > {
  >"config":{
  >   "identity":{
  >  "driver":"ldap"
  >   },
  >   "ldap":{
  >  .
  >  "tls_req_cert":"demand",
  >  "user_tree_dn":"ou=Users50,dc=cdl,dc=hp,dc=com",
  >  "group_allow_update":"False"
  >   }
  >}
  > } ' \
  >   -XPUT "http://localhost:35357/v3/domains/123456789/config/;

  {"config": {"identity": {"driver":
  "keystone.identity.backends.ldap.Identity"}, "ldap":
  {"user_allow_update": "False", "user_name_attribute": "cn",
  "use_pool": "True", "user_objectclass": "posixAccount",
  "group_id_attribute": "gidNumber", "user_allow_create": "False",
  "tls_req_cert": "demand"...}}}

  Once the config options created in the database, the user can even use
  this invalid domain id to get/update/delete the config options, an
  example as shown below:

  ~$ curl -k -H "X-Auth-Token:ADMIN"
  http://localhost:35357/v3/domains/123456789/config/

  {"config": {"identity": {"driver":
  "keystone.identity.backends.ldap.Identity"}, "ldap":
  {"user_allow_update": "False", "group_allow_delete": "False",
  "group_name_attribute": "cn", "suffix": "dc=cdl,dc=hp,dc=com", ..,
  "group_allow_update": "False"...}}}

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1524562/+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 1525295] Re: subnet listing is too slow with rbac

2015-12-15 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/256609
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=f5b950dffecc049df11981dcfb5574121be3eb69
Submitter: Jenkins
Branch:master

commit f5b950dffecc049df11981dcfb5574121be3eb69
Author: Kevin Benton 
Date:   Fri Dec 11 09:56:01 2015 -0800

Separate rbac calculation from _make_network_dict

When a subnet dict was being created, it was calling
_make_network_dict to get the 'shared' flag for the
subnet. The issue with this is that the _make_network_dict
function would iterate over the subnets on the passed in
network object, which would trigger a database lookup
of all of the subnets.

This patch just separates the 'shared' flag calculation out
into a separate function that both calls can leverage.

Change-Id: I2cb766ce1fd8ddcc75209f9e92221a3b77015ea2
Closes-Bug: #1525295
Partial-Bug: #1513782


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

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

Title:
  subnet listing is too slow with rbac

Status in neutron:
  Fix Released

Bug description:
  subnet listing of 100 subnets takes about 2 seconds on a powerfull hardware.
  60% of the time is consumed by the calculation of 'shared' attribute of the 
subnet which involves rbac rules.

  This makes horizon barely usable as number of networks grow.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1525295/+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 1525423] Re: get_networks performance hindered by segment lookups

2015-12-15 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/256846
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=806e67538fbea49530aa0eedb75694cd8bad439d
Submitter: Jenkins
Branch:master

commit 806e67538fbea49530aa0eedb75694cd8bad439d
Author: Kevin Benton 
Date:   Fri Dec 11 10:55:38 2015 -0800

Batch db segment retrieval

A net-list operation was calling extend_network_dict_provider for
each network individually which would result in a database call for
each network.

This adds a new call in the manager to extend multiple networks at
once and then it adds a bulk version of get_network_segments that
it calls.

Now 1 net list of any number of networks will only result in 1
segment DB call.

Change-Id: I2543b3bdbb178ee4bb8d1288e9a27af1c5c8c8b4
Closes-Bug: #1525423
Partial-Bug: #1513782


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

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

Title:
  get_networks performance hindered by segment lookups

Status in neutron:
  Fix Released

Bug description:
  During the get_networks method of ML2, we iterate over each network
  and do a database call to lookup the segments for that network. This
  scales the number of database calls linearly with the number of
  retrieved networks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1525423/+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 1526369] [NEW] nova.tests.unit.virt.xenapi.test_vmops.BootableTestCase.test_set_bootable is racy on py34

2015-12-15 Thread Matt Riedemann
Public bug reported:

http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22mox3.mox.UnexpectedMethodCallError:%20Unexpected%20method%20call%20function.__call__(%3Cnova.virt.xenapi.client.session.XenAPISession%5C%22%20AND%20tags:%5C%22console%5C%22%20AND%20build_name:%5C
%22gate-nova-python34%5C%22

ft1.7942: 
nova.tests.unit.virt.xenapi.test_vmops.BootableTestCase.test_set_bootable_StringException:
 Empty attachments:
  stdout

pythonlogging:'': {{{2015-12-15 13:33:23,562 WARNING 
[oslo_reports.guru_meditation_report] Guru mediation now registers SIGUSR1 and 
SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be 
registered in a future release, so please use SIGUSR2 to generate reports.}}}
stderr: {{{
/home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/site-packages/pkg_resources/__init__.py:213:
 RuntimeWarning: You have iterated over the result of 
pkg_resources.parse_version. This is a legacy behavior which is inconsistent 
with the new version class introduced in setuptools 8.0. In most cases, 
conversion to a tuple is unnecessary. For comparison of versions, sort the 
Version instances directly. If you have another use case requiring the tuple, 
please file a bug with the setuptools project describing that need.
  stacklevel=1,
}}}

Traceback (most recent call last):
  File 
"/home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/site-packages/mox3/mox.py",
 line 1153, in _PopNextMethod
return self._call_queue.popleft()
IndexError: pop from an empty deque

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/home/jenkins/workspace/gate-nova-python34/nova/tests/unit/virt/xenapi/test_vmops.py",
 line 1044, in test_set_bootable
self.vmops.set_bootable(self.instance, True)
  File "/home/jenkins/workspace/gate-nova-python34/nova/virt/xenapi/vmops.py", 
line 1621, in set_bootable
vm_ref = self._get_vm_opaque_ref(instance)
  File "/home/jenkins/workspace/gate-nova-python34/nova/virt/xenapi/vmops.py", 
line 824, in _get_vm_opaque_ref
vm_ref = vm_utils.lookup(self._session, instance['name'], check_rescue)
  File 
"/home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/site-packages/mox3/mox.py",
 line 814, in __call__
return mock_method(*params, **named_params)
  File 
"/home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/site-packages/mox3/mox.py",
 line 1113, in __call__
expected_method = self._VerifyMethodCall()
  File 
"/home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/site-packages/mox3/mox.py",
 line 1169, in _VerifyMethodCall
expected = self._PopNextMethod()
  File 
"/home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/site-packages/mox3/mox.py",
 line 1155, in _PopNextMethod
raise UnexpectedMethodCallError(self, None)
mox3.mox.UnexpectedMethodCallError: Unexpected method call 
function.__call__(, 'test', False) -> None

7 hits in 7 days, check and gate, py34 only, this is just mox3 being
racy on py34.

** Affects: nova
 Importance: Undecided
 Status: Confirmed


** Tags: py34 testing xenserver

** Changed in: nova
   Status: New => Confirmed

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

Title:
  nova.tests.unit.virt.xenapi.test_vmops.BootableTestCase.test_set_bootable
  is racy on py34

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  
http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22mox3.mox.UnexpectedMethodCallError:%20Unexpected%20method%20call%20function.__call__(%3Cnova.virt.xenapi.client.session.XenAPISession%5C%22%20AND%20tags:%5C%22console%5C%22%20AND%20build_name:%5C
  %22gate-nova-python34%5C%22

  ft1.7942: 
nova.tests.unit.virt.xenapi.test_vmops.BootableTestCase.test_set_bootable_StringException:
 Empty attachments:
stdout

  pythonlogging:'': {{{2015-12-15 13:33:23,562 WARNING 
[oslo_reports.guru_meditation_report] Guru mediation now registers SIGUSR1 and 
SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be 
registered in a future release, so please use SIGUSR2 to generate reports.}}}
  stderr: {{{
  
/home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/site-packages/pkg_resources/__init__.py:213:
 RuntimeWarning: You have iterated over the result of 
pkg_resources.parse_version. This is a legacy behavior which is inconsistent 
with the new version class introduced in setuptools 8.0. In most cases, 
conversion to a tuple is unnecessary. For comparison of versions, sort the 
Version instances directly. If you have another use case requiring the tuple, 
please file a bug with the setuptools project describing that need.
stacklevel=1,
  }}}

  Traceback (most recent call last):
File 

[Yahoo-eng-team] [Bug 1525464] Re: Release request of networking-cisco and creation of stable/liberty 2.0.0

2015-12-15 Thread Kyle Mestery
This is on PyPI now: https://pypi.python.org/pypi/networking-cisco/2.0.0

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

** Changed in: neutron
Milestone: None => mitaka-2

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

Title:
  Release request of networking-cisco and creation of stable/liberty
  2.0.0

Status in networking-cisco:
  New
Status in neutron:
  Fix Released

Bug description:
  networking-cisco has NOT yet been branched for stable/liberty this
  needs to be done alone with tagging the first release at 2.0.0

  Branch and tag at hash: cccaa1d12b81e17756dbef216048d76d008df54d

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-cisco/+bug/1525464/+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 1526199] [NEW] volumes have no attribute tenant_name gives error

2015-12-15 Thread zhu.rong
Public bug reported:

Volumes have no attribute tenant_name, gives the error like:
The attribute tenant_name doesn't exist on .

** Affects: horizon
 Importance: Undecided
 Assignee: zhu.rong (zhu-rong)
 Status: In Progress

** Changed in: horizon
 Assignee: (unassigned) => zhu.rong (zhu-rong)

** Description changed:

- Volumes have no attribute version, gives the error like:
+ Volumes have no attribute tenant_name, gives the error like:
  The attribute tenant_name doesn't exist on .

-- 
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/1526199

Title:
  volumes have no attribute tenant_name gives error

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  Volumes have no attribute tenant_name, gives the error like:
  The attribute tenant_name doesn't exist on .

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1526199/+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 1526245] [NEW] Add option for nova endpoint type

2015-12-15 Thread OpenStack Infra
Public bug reported:

https://review.openstack.org/254900
Dear bug triager. This bug was created since a commit was marked with DOCIMPACT.
Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

commit 7dad96deb4ae66509d968465bcd1c852c6743bc1
Author: Jeremy McDermond 
Date:   Tue Dec 8 10:14:09 2015 -0800

Add option for nova endpoint type

When the neutron notification to nova was updated to use novaclient the
nova_url parameter was disabled.  This prevents administrators from
using anything but the publicURL as the proper endpoint to notify nova.
This patch adds an option to pass on to novaclient for the
endpoint_type so that the administrator can set the notification url to
public, internal or admin.

Change-Id: I405f76199cab6b8c8895f98419f79cd74cad
Closes-Bug: #1478471
DocImpact: Need to add a new option to the neutron configuration
reference.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: neutron

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

Title:
  Add option for nova endpoint type

Status in neutron:
  New

Bug description:
  https://review.openstack.org/254900
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 7dad96deb4ae66509d968465bcd1c852c6743bc1
  Author: Jeremy McDermond 
  Date:   Tue Dec 8 10:14:09 2015 -0800

  Add option for nova endpoint type
  
  When the neutron notification to nova was updated to use novaclient the
  nova_url parameter was disabled.  This prevents administrators from
  using anything but the publicURL as the proper endpoint to notify nova.
  This patch adds an option to pass on to novaclient for the
  endpoint_type so that the administrator can set the notification url to
  public, internal or admin.
  
  Change-Id: I405f76199cab6b8c8895f98419f79cd74cad
  Closes-Bug: #1478471
  DocImpact: Need to add a new option to the neutron configuration
  reference.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1526245/+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 1207599] Re: Test failing due to latest version of openstack_auth

2015-12-15 Thread Lin Hua Cheng
** Changed in: horizon/folsom
   Status: Fix Committed => 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/1207599

Title:
  Test failing due to latest version of openstack_auth

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Dashboard (Horizon) folsom series:
  Fix Released
Status in OpenStack Dashboard (Horizon) grizzly series:
  Fix Released

Bug description:
  Horizon jobs are failing due to incompatibility with openstack_auth

  2013-08-02 00:37:02.136 | 
==
  2013-08-02 00:37:02.136 | ERROR: 
test_update_project_member_update_error_domain 
(openstack_dashboard.dashboards.admin.projects.tests.UpdateProjectWorkflowTests)
  2013-08-02 00:37:02.136 | 
--
  2013-08-02 00:37:02.136 | Traceback (most recent call last):
  2013-08-02 00:37:02.136 |   File 
"/home/jenkins/workspace/gate-horizon-python26/openstack_dashboard/dashboards/admin/projects/tests.py",
 line 1242, in test_update_project_member_update_error_domain
  2013-08-02 00:37:02.136 | self.test_update_project_member_update_error()
  2013-08-02 00:37:02.136 |   File 
"/home/jenkins/workspace/gate-horizon-python26/openstack_dashboard/test/helpers.py",
 line 77, in instance_stub_out
  2013-08-02 00:37:02.137 | return fn(self)
  2013-08-02 00:37:02.137 |   File 
"/home/jenkins/workspace/gate-horizon-python26/openstack_dashboard/dashboards/admin/projects/tests.py",
 line 1232, in test_update_project_member_update_error
  2013-08-02 00:37:02.137 | res = self.client.post(url, workflow_data)
  2013-08-02 00:37:02.137 |   File 
"/home/jenkins/workspace/gate-horizon-python26/.tox/py26/lib/python2.6/site-packages/django/test/client.py",
 line 463, in post
  2013-08-02 00:37:02.137 | response = super(Client, self).post(path, 
data=data, content_type=content_type, **extra)
  2013-08-02 00:37:02.137 |   File 
"/home/jenkins/workspace/gate-horizon-python26/.tox/py26/lib/python2.6/site-packages/django/test/client.py",
 line 297, in post
  2013-08-02 00:37:02.137 | return self.request(**r)
  2013-08-02 00:37:02.137 |   File 
"/home/jenkins/workspace/gate-horizon-python26/.tox/py26/lib/python2.6/site-packages/django/test/client.py",
 line 424, in request
  2013-08-02 00:37:02.137 | six.reraise(*exc_info)
  2013-08-02 00:37:02.138 |   File 
"/home/jenkins/workspace/gate-horizon-python26/.tox/py26/lib/python2.6/site-packages/django/core/handlers/base.py",
 line 115, in get_response
  2013-08-02 00:37:02.138 | response = callback(request, *callback_args, 
**callback_kwargs)
  2013-08-02 00:37:02.138 |   File 
"/home/jenkins/workspace/gate-horizon-python26/horizon/decorators.py", line 38, 
in dec
  2013-08-02 00:37:02.138 | return view_func(request, *args, **kwargs)
  2013-08-02 00:37:02.138 |   File 
"/home/jenkins/workspace/gate-horizon-python26/horizon/decorators.py", line 84, 
in dec
  2013-08-02 00:37:02.138 | if request.user.is_authenticated():
  2013-08-02 00:37:02.138 |   File 
"/home/jenkins/workspace/gate-horizon-python26/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py",
 line 189, in is_authenticated
  2013-08-02 00:37:02.138 | return self.token is not None and 
check_token_expiration(self.token)
  2013-08-02 00:37:02.138 |   File 
"/home/jenkins/workspace/gate-horizon-python26/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py",
 line 55, in check_token_expiration
  2013-08-02 00:37:02.138 | if settings.USE_TZ and 
timezone.is_naive(expiration):
  2013-08-02 00:37:02.139 |   File 
"/home/jenkins/workspace/gate-horizon-python26/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py",
 line 272, in is_naive
  2013-08-02 00:37:02.139 | return value.tzinfo is None or 
value.tzinfo.utcoffset(value) is None
  2013-08-02 00:37:02.139 | AttributeError: 'str' object has no attribute 
'tzinfo'

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1207599/+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 1308642] Re: Missing comma in the _attrs of Volume Resource Wrapper

2015-12-15 Thread Lin Hua Cheng
** Changed in: horizon/icehouse
   Status: Fix Committed => 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/1308642

Title:
  Missing comma in the _attrs of Volume Resource Wrapper

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Dashboard (Horizon) icehouse series:
  Fix Released

Bug description:
  Missing comma after 'bootable'

  
  
https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/cinder.py#L81

  class Volume(BaseCinderAPIResourceWrapper):

  _attrs = ['id', 'name', 'description', 'size', 'status', 'created_at',
'volume_type', 'availability_zone', 'imageRef', 'bootable'
'snapshot_id', 'source_volid', 'attachments', 'tenant_name',
'os-vol-host-attr:host', 'os-vol-tenant-attr:tenant_id',
'metadata']

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1308642/+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 1526279] Re: murano-agent can't ship binary file to nova instance

2015-12-15 Thread TonyWang
** Project changed: horizon => murano

-- 
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/1526279

Title:
  murano-agent can't ship binary file to nova instance

Status in Murano:
  New

Bug description:
  1. I want to use murano-agent to ship rpm package to nova instance, and got 
the following error:
  2015-12-15 10:05:33.735 1 ERROR murano.common.engine [-] 
exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xed in 
position 0: ordinal not in range(128)
Traceback (most recent call last):
  File 
"/tmp/murano-packages-cache/585c671065534988ba95fc81fe9dcc2e/3e0ed1ccc50f4e189612969273768666/Classes/Environment.yaml",
 line 82:9 in method deploy of class io.murano.Environment
  $.applications.pselect($.deploy())
  File 
"/tmp/murano-packages-cache/585c671065534988ba95fc81fe9dcc2e/f69c326e5cc5401881a7701f300f319b/Classes/MRF.yaml",
 line 249:13 in method deploy of class com.alu.apps.mrf.MRF
  $.mistralAgent.call($template, $resources)
  File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 45 in 
method evaluate
  return value(context)
  File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_expression.py", 
line 82 in method __call__
  return self._parsed_expression.evaluate(context=context)
  File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", 
line 165 in method evaluate
  return self(utils.NO_VALUE, context, self.engine)
  File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", 
line 156 in method __call__
  return super(Statement, self).__call__(receiver, context, engine)
  File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", 
line 37 in method __call__
  return context(self.name, engine, receiver, context)(*self.args)
  File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 
65 in method 
  data_context, use_convention, function_filter)
  File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 49 
in method call
  name, all_overloads, engine, receiver, data_context, args, kwargs)
  File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method choose_overload
  args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
  File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method 
  args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
  File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 113 
in method 
  and not isinstance(arg, expressions.Constant))
  File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", 
line 37 in method __call__
  return context(self.name, engine, receiver, context)(*self.args)
  File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 
65 in method 
  data_context, use_convention, function_filter)
  File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 51 
in method call
  result = delegate()
  File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 142 
in method 
  return lambda: delegate()
  File "/usr/lib/python2.7/site-packages/yaql/language/specs.py", line 341 
in method func
  six.iteritems(keyword_args)))
  File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_functions.py", 
line 140 in method op_dot
  return operator(ctx2, sender, expr)
  File "/usr/lib/python2.7/site-packages/yaql/language/yaqltypes.py", line 
290 in method func
  new_name, engine, new_receiver, new_context)(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 
65 in method 
  data_context, use_convention, function_filter)
  File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 51 
in method call
  result = delegate()
  File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 142 
in method 
  return lambda: delegate()
  File "/usr/lib/python2.7/site-packages/yaql/language/specs.py", line 341 
in method func
  six.iteritems(keyword_args)))
  File "/usr/lib/python2.7/site-packages/yaql/standard_library/system.py", 
line 34 in method op_dot
  return expr(receiver)
  File "/usr/lib/python2.7/site-packages/yaql/language/yaqltypes.py", line 
236 in method func
  engine, args, kwargs)
  File "/usr/lib/python2.7/site-packages/yaql/language/yaqltypes.py", line 
205 in method _call
  result = value(receiver, context, engine)
  File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", 
line 37 in method __call__
  return context(self.name, engine, receiver, context)(*self.args)
  File 

[Yahoo-eng-team] [Bug 1526300] [NEW] openstack client in Mistal can't support to change the endpoint_type

2015-12-15 Thread TonyWang
Public bug reported:

In my OpenStack environment, publicURL of all the OpenStack services are based 
on HTTPS, and internalURL is based on HTTP. I want Mistral to use internalURL 
to access other OpenStack services, but looks like the "endpoint_type" is hard 
coded as shown here:
NovaAction._get_client
def _get_client(self):
ctx = context.ctx()

LOG.debug("Nova action security context: %s" % ctx)

keystone_endpoint = keystone_utils.get_keystone_endpoint_v2()
nova_endpoint = keystone_utils.get_endpoint_for_project('nova')

client = self._client_class(
username=None,
api_key=None,
endpoint_type='publicURL', < Here it is hard coded.
service_type='compute',
auth_token=ctx.auth_token,
tenant_id=ctx.project_id,
region_name=keystone_endpoint.region,
auth_url=keystone_endpoint.url
)

client.client.management_url = keystone_utils.format_url(
nova_endpoint.url,
{'tenant_id': ctx.project_id}
)

return client

If it can be configurable, it will be great.

Thanks,
Tony

** Affects: mistral
 Importance: Undecided
 Status: New

** Project changed: horizon => mistral

-- 
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/1526300

Title:
  openstack client in Mistal can't support to change the endpoint_type

Status in Mistral:
  New

Bug description:
  In my OpenStack environment, publicURL of all the OpenStack services are 
based on HTTPS, and internalURL is based on HTTP. I want Mistral to use 
internalURL to access other OpenStack services, but looks like the 
"endpoint_type" is hard coded as shown here:
  NovaAction._get_client
  def _get_client(self):
  ctx = context.ctx()

  LOG.debug("Nova action security context: %s" % ctx)

  keystone_endpoint = keystone_utils.get_keystone_endpoint_v2()
  nova_endpoint = keystone_utils.get_endpoint_for_project('nova')

  client = self._client_class(
  username=None,
  api_key=None,
  endpoint_type='publicURL', < Here it is hard coded.
  service_type='compute',
  auth_token=ctx.auth_token,
  tenant_id=ctx.project_id,
  region_name=keystone_endpoint.region,
  auth_url=keystone_endpoint.url
  )

  client.client.management_url = keystone_utils.format_url(
  nova_endpoint.url,
  {'tenant_id': ctx.project_id}
  )

  return client

  If it can be configurable, it will be great.

  Thanks,
  Tony

To manage notifications about this bug go to:
https://bugs.launchpad.net/mistral/+bug/1526300/+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 1526279] [NEW] murano-agent can't ship binary file to nova instance

2015-12-15 Thread TonyWang
Public bug reported:

1. I want to use murano-agent to ship rpm package to nova instance, and got the 
following error:
2015-12-15 10:05:33.735 1 ERROR murano.common.engine [-] 
  exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xed in 
position 0: ordinal not in range(128)
  Traceback (most recent call last):
File 
"/tmp/murano-packages-cache/585c671065534988ba95fc81fe9dcc2e/3e0ed1ccc50f4e189612969273768666/Classes/Environment.yaml",
 line 82:9 in method deploy of class io.murano.Environment
$.applications.pselect($.deploy())
File 
"/tmp/murano-packages-cache/585c671065534988ba95fc81fe9dcc2e/f69c326e5cc5401881a7701f300f319b/Classes/MRF.yaml",
 line 249:13 in method deploy of class com.alu.apps.mrf.MRF
$.mistralAgent.call($template, $resources)
File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 45 in 
method evaluate
return value(context)
File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_expression.py", line 
82 in method __call__
return self._parsed_expression.evaluate(context=context)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
165 in method evaluate
return self(utils.NO_VALUE, context, self.engine)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
156 in method __call__
return super(Statement, self).__call__(receiver, context, engine)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
37 in method __call__
return context(self.name, engine, receiver, context)(*self.args)
File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 
in method 
data_context, use_convention, function_filter)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 49 in 
method call
name, all_overloads, engine, receiver, data_context, args, kwargs)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method choose_overload
args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 
in method 
args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args))
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 113 
in method 
and not isinstance(arg, expressions.Constant))
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
37 in method __call__
return context(self.name, engine, receiver, context)(*self.args)
File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 
in method 
data_context, use_convention, function_filter)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 51 in 
method call
result = delegate()
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 142 
in method 
return lambda: delegate()
File "/usr/lib/python2.7/site-packages/yaql/language/specs.py", line 341 in 
method func
six.iteritems(keyword_args)))
File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_functions.py", line 
140 in method op_dot
return operator(ctx2, sender, expr)
File "/usr/lib/python2.7/site-packages/yaql/language/yaqltypes.py", line 
290 in method func
new_name, engine, new_receiver, new_context)(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 
in method 
data_context, use_convention, function_filter)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 51 in 
method call
result = delegate()
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 142 
in method 
return lambda: delegate()
File "/usr/lib/python2.7/site-packages/yaql/language/specs.py", line 341 in 
method func
six.iteritems(keyword_args)))
File "/usr/lib/python2.7/site-packages/yaql/standard_library/system.py", 
line 34 in method op_dot
return expr(receiver)
File "/usr/lib/python2.7/site-packages/yaql/language/yaqltypes.py", line 
236 in method func
engine, args, kwargs)
File "/usr/lib/python2.7/site-packages/yaql/language/yaqltypes.py", line 
205 in method _call
result = value(receiver, context, engine)
File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 
37 in method __call__
return context(self.name, engine, receiver, context)(*self.args)
File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 
in method 
data_context, use_convention, function_filter)
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 51 in 
method call
result = delegate()
File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 142 
in method 
return lambda: delegate()
File "/usr/lib/python2.7/site-packages/yaql/language/specs.py", line 341 in 
method 

[Yahoo-eng-team] [Bug 1478471] Re: neutron can't use internal nova-api url for notification with v3 auth

2015-12-15 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/254900
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=7dad96deb4ae66509d968465bcd1c852c6743bc1
Submitter: Jenkins
Branch:master

commit 7dad96deb4ae66509d968465bcd1c852c6743bc1
Author: Jeremy McDermond 
Date:   Tue Dec 8 10:14:09 2015 -0800

Add option for nova endpoint type

When the neutron notification to nova was updated to use novaclient the
nova_url parameter was disabled.  This prevents administrators from
using anything but the publicURL as the proper endpoint to notify nova.
This patch adds an option to pass on to novaclient for the
endpoint_type so that the administrator can set the notification url to
public, internal or admin.

Change-Id: I405f76199cab6b8c8895f98419f79cd74cad
Closes-Bug: #1478471
DocImpact: Need to add a new option to the neutron configuration
reference.


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

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

Title:
  neutron can't use internal nova-api url for notification with v3 auth

Status in neutron:
  Fix Released

Bug description:
  Hi!

  When the v3 auth plugin is used for notifying nova on changes, the
  config parameter nova_url is ignored and neutron uses public endpoint
  automatically. If internalURL and publicURL are not the same, and
  publicURL is not accessible for internal services, than the
  notification will fail and so will VM creation. I tried to look for
  any config parmeter to change this behavior, but couldn't find any.

  OS: Ubuntu 14.04
  Neutron version: 1:2015.1.0-0ubuntu1~cloud0

  my nova endpoints:
  +--+-+
  | Field| Value   |
  +--+-+
  | adminurl | http://192.168.56.10:8774/v2/%(tenant_id)s  |
  | enabled  | True|
  | id   | 3706c3fe985c4219a145a7ec83c14955|
  | internalurl  | http://192.168.56.10:8774/v2/%(tenant_id)s  |
  | publicurl| https://192.168.55.10:8774/v2/%(tenant_id)s |
  | region   | labor   |
  | service_id   | ebc286c9356449819d2c7a7a5fbd1c77|
  | service_name | nova|
  | service_type | compute |
  +--+-+

  partial log:
  2015-07-23 11:31:06.021 24522 DEBUG keystoneclient.auth.identity.v3 [-] 
Making authentication request to http://192.168.56.10:35357/v3/auth/tokens 
get_auth_ref 
/usr/lib/python2.7/dist-packages/keystoneclient/auth/identity/v3.py:125
  2015-07-23 11:31:06.385 24522 DEBUG keystoneclient.session [-] REQ: curl -g 
-i -X POST 
https://192.168.55.10:8774/v2/d239fb491e944da39e430174dc5fd33e/os-server-external-events
 -H "User-Agent: python-novaclient" -H "Content-Type: applicat$
  2015-07-23 11:31:06.443 24522 ERROR neutron.notifiers.nova [-] Failed to 
notify nova on events: [{'status': 'completed', 'tag': 
u'2a6ce600-1c57-4f91-a17e-1623adf9e1ee', 'name': 'network-vif-plugged', 
'server_uuid': u'f77b2756-99ed-4259-b$
  2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova Traceback (most 
recent call last):
  2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova   File 
"/usr/lib/python2.7/dist-packages/neutron/notifiers/nova.py", line 243, in 
send_events
  2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova batched_events)
  2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova   File 
"/usr/lib/python2.7/dist-packages/novaclient/v2/contrib/server_external_events.py",
 line 39, in create
  2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova 
return_raw=True)
  2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova   File 
"/usr/lib/python2.7/dist-packages/novaclient/base.py", line 152, in _create
  2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova _resp, body = 
self.api.client.post(url, body=body)
  2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova   File 
"/usr/lib/python2.7/dist-packages/keystoneclient/adapter.py", line 170, in post
  2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova return 
self.request(url, 'POST', **kwargs)
  2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova   File 
"/usr/lib/python2.7/dist-packages/novaclient/client.py", line 89, in request
  2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova **kwargs)
  2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova   File 
"/usr/lib/python2.7/dist-packages/keystoneclient/adapter.py", line 200, in 
request
  2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova resp = 
super(LegacyJsonAdapter, 

[Yahoo-eng-team] [Bug 1508869] Re: DVR: handle dvr serviceable port's host change

2015-12-15 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/238478
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=189a6f1bc3295b719304f44e5b731ef671fe7f50
Submitter: Jenkins
Branch:master

commit 189a6f1bc3295b719304f44e5b731ef671fe7f50
Author: Oleg Bondarev 
Date:   Thu Oct 22 13:23:21 2015 +0300

DVR: handle dvr serviceable port's host change

When a VM port's host is changed we need to check if a router
should be unscheduled from old host and send corresponding
notifications.
commit d5a8074ec3c67ed68e64a96827da990f1c34e10f added such
a check when port is unbound. This patch adds similar check
in case of host change (instance live migration)

Closes-Bug: #1508869

Change-Id: I57fa8253b2c88f7b7380a79b841fc424e9e52f19


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

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

Title:
  DVR: handle dvr serviceable port's host change

Status in neutron:
  Fix Released

Bug description:
  When a VM port's host is changed we need to check if router should be 
unscheduled from old host and send corresponding notifications.
  commit d5a8074ec3c67ed68e64a96827da990f1c34e10f added such a check when port 
is unbound. Need to add similar check in case of host change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1508869/+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 1490804] Re: PKI Token Revocation Bypass (CVE-2015-7546)

2015-12-15 Thread OpenStack Infra
** Changed in: keystone
   Status: Won't Fix => In Progress

** Changed in: keystone
 Assignee: Adam Young (ayoung) => Brant Knudson (blk-u)

** Changed in: keystonemiddleware
   Status: Won't Fix => In Progress

** Changed in: keystonemiddleware
 Assignee: Adam Young (ayoung) => Brant Knudson (blk-u)

-- 
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/1490804

Title:
  PKI Token Revocation Bypass (CVE-2015-7546)

Status in django-openstack-auth:
  Invalid
Status in OpenStack Identity (keystone):
  In Progress
Status in keystonemiddleware:
  In Progress
Status in OpenStack Security Advisory:
  Incomplete
Status in OpenStack Security Notes:
  New
Status in python-keystoneclient:
  Won't Fix

Bug description:
  A keystone token which has been revoked can still be used by manipulating 
particular byte fields within the token.
  When a Keystone token is revoked it is added to the revoked list which stores 
the exact token value. Any API will look at the token to see whether or not it 
should accept a token. By changing a single byte within the token, the 
revocation can be bypassed.  see the testing script [1].

  It is suggested that the revocation should be changed to only check
  the token's inner ID.

  [1] http://paste.openstack.org/show/436516/

To manage notifications about this bug go to:
https://bugs.launchpad.net/django-openstack-auth/+bug/1490804/+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 1526559] [NEW] L3 agent parallel configuration of routers might slow things down

2015-12-15 Thread Assaf Muller
Public bug reported:

In the L3 agent's _process_routers_loop method, it spawns a GreenPool
with 8 eventlet threads. Those threads then take updates off the agent's
queue and process router updates. Router updates are serialized by
router_id so that two threads don't process the same router at any given
time.

In an environment running on a powerful baremetal server, on agent
restart it was trying to sync roughly 600 routers. Around half were HA
routers, and half were legacy routers. With the default GreenPool size
of 8, the result was that the server ground to a halt as CPU usage
skyrocketed to over 600%. The main offenders were ip, bash, keepalived
and Python. This was on an environment without rootwrap daemon based off
stable/juno. It took around 60 seconds to configure a single router.
Changing the GreenPool size from 8 to 1, caused the agent to:

1) Configure a router in 30 seconds, a 50% improvement.
2) Reduce CPU load from 600% to 70%, freeing the machine to do other things.

I'm filing this bug so that:

1) Someone can confirm my personal experience in a more controlled way - For 
example, graph router configuration time and CPU load as a result of GreenPool 
size.
2) If my findings are confirmed on master with rootwrap daemon, start 
considering alternatives like multiprocessing instead of eventlet 
multithreading, or at the very least optimize the GreenPool size.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: l3-ipam-dhcp loadimpact

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

Title:
  L3 agent parallel configuration of routers might slow things down

Status in neutron:
  New

Bug description:
  In the L3 agent's _process_routers_loop method, it spawns a GreenPool
  with 8 eventlet threads. Those threads then take updates off the
  agent's queue and process router updates. Router updates are
  serialized by router_id so that two threads don't process the same
  router at any given time.

  In an environment running on a powerful baremetal server, on agent
  restart it was trying to sync roughly 600 routers. Around half were HA
  routers, and half were legacy routers. With the default GreenPool size
  of 8, the result was that the server ground to a halt as CPU usage
  skyrocketed to over 600%. The main offenders were ip, bash, keepalived
  and Python. This was on an environment without rootwrap daemon based
  off stable/juno. It took around 60 seconds to configure a single
  router. Changing the GreenPool size from 8 to 1, caused the agent to:

  1) Configure a router in 30 seconds, a 50% improvement.
  2) Reduce CPU load from 600% to 70%, freeing the machine to do other things.

  I'm filing this bug so that:

  1) Someone can confirm my personal experience in a more controlled way - For 
example, graph router configuration time and CPU load as a result of GreenPool 
size.
  2) If my findings are confirmed on master with rootwrap daemon, start 
considering alternatives like multiprocessing instead of eventlet 
multithreading, or at the very least optimize the GreenPool size.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1526559/+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 1500365] Re: neutron port API does not support atomicity

2015-12-15 Thread Armando Migliaccio
Based on discussion [1], if this becomes a burning issue for some other
more realistic use case, we can consider introducing an atomic update of
the device id and/or device owner field.

[1]
http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-12-15-15.01.log.html

** Changed in: neutron
   Status: Triaged => Won't Fix

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

Title:
  neutron port API does not support atomicity

Status in neutron:
  Won't Fix

Bug description:
  Neutron port API offers an update method where the user of the API can say "I 
use this port" by setting the device_owner and device_id fields of the port. 
However the neutron API does not prevent port allocation race conditions.
  The API semantic is that a port is used if the device_id and the device_owner 
fields are set, and not used if they aren't.  Now lets have two clients that 
both want to set the ownership of the port. Both clients first have to check if 
the port is free or not by checking the value of the device_owner and device_id 
fields of the port, then they have to set the those fields to express 
ownership. 
  If the two clients act parallel it is pretty much possible that both clients 
see that the fields are empty and both issue the port update command. This can 
leads to race conditions between clients.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1500365/+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 1518643] Re: Nuage vendor code still present in neutron tree

2015-12-15 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/255459
Committed: 
https://git.openstack.org/cgit/openstack/python-neutronclient/commit/?id=a0e20366cf30596a519ce49f2837b3dd575ee8d5
Submitter: Jenkins
Branch:master

commit a0e20366cf30596a519ce49f2837b3dd575ee8d5
Author: Manjeet Singh Bhatia 
Date:   Wed Dec 9 19:51:23 2015 +

Remove nuage plugin from client

This remove the nuage code from client

Change-Id: I7a3bdbedc429015258e76506da950226cacb07e8
Closes-Bug: #1518643


** Changed in: python-neutronclient
   Status: In Progress => Fix Released

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

Title:
  Nuage vendor code still present in neutron tree

Status in neutron:
  Fix Released
Status in python-neutronclient:
  Fix Released

Bug description:
  The Nuage plugins and ML2 mechanism drivers should be completely
  removed from the neutron tree.

  See http://docs.openstack.org/developer/neutron/devref/contribute.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1518643/+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 1457986] Re: RFE: Need API to provide network IP allocation counts

2015-12-15 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/180803
Committed: 
https://git.openstack.org/cgit/openstack/neutron-specs/commit/?id=8a8a48216da5fe9c92cf6071a964964f9ef89fbd
Submitter: Jenkins
Branch:master

commit 8a8a48216da5fe9c92cf6071a964964f9ef89fbd
Author: dbingham 
Date:   Mon Nov 30 18:54:14 2015 -0700

Network IP Availability Extension API

Add a new network IP availability API Extension for operators to predict
and react when networks are reaching IP capacity.

ip availability api extension rfe

APIImpact
DocImpact

Change-Id: Ifd42982aea5bbfc095e30bd2a221ec472d55519a
Implements: blueprint network-ip-usage-api
Closes-Bug: 1457986


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

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

Title:
  RFE: Need API to provide network IP allocation counts

Status in neutron:
  Fix Released

Bug description:
  Operators have requested an API that allows them to quickly and easily
  determine the IP capacity of a network or subnet. Rather than
  discovering a network is full, an api could be proactively called by
  an operator or monitor to give some measure of when a network is
  reaching its capacity.

  Some things desired from a new API for both network and subnets
  * used IPs - How many IPs are reserved from a network/subnet
  * total IPs - The capacity of IPs for this network/subnet
  * Enough information about the network/subnet to be able to fetch detailed 
information about the resource (possible examples: id, name)

  Naturally used_ips/total_ips gives the user a way to determine the
  percentage the resource has been consumed.

  Some references to those needing this API:
  * Philidelphia operators at the OPs meetup expressed great interest after 
watching a presentation describing this use.
  * GoDaddy in-house implementation: In use for 1+ years. Also called by 
in-house NetworkAwareFilterScheduler. GoDaddy 
implementation:https://github.com/godaddy/openstack-neutron/commit/fcf325f9f9f7a9f87ba6bc1c53f9212d0e2decee
  * Rackspace implementation: 
https://github.com/rackerlabs/quark/blob/master/quark/ip_availability.py#L48

  Some notes about related patches (added 2015-11-17):
  * https://review.openstack.org/180803 (Neutron Spec)
  * https://review.openstack.org/#/c/212955 (Neutron patch)
  * https://review.openstack.org/#/c/234541 (Second Neutron patch)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1457986/+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 1523716] Re: oslo.utils upgrade breaks unit tests

2015-12-15 Thread Henry Gessau
Neutron no longer affected after oslo.utils 3.2.0 released

** Changed in: neutron
   Status: New => Invalid

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

Title:
  oslo.utils upgrade breaks unit tests

Status in Ceilometer:
  Invalid
Status in Magnum:
  New
Status in networking-odl:
  New
Status in neutron:
  Invalid
Status in oslo.utils:
  Fix Released

Bug description:
  Upgraded oslo.utils (3.1.0) is breaking ceilometer unit tests:

  https://jenkins07.openstack.org/job/gate-ceilometer-
  python34/897/console

  Stack Trace:

  2015-12-07 20:17:19.296 | __import__(module_str)
  2015-12-07 20:17:19.296 |   File "ceilometer/notification.py", line 24, in 

  2015-12-07 20:17:19.296 | from ceilometer import coordination
  2015-12-07 20:17:19.296 |   File "ceilometer/coordination.py", line 20, in 

  2015-12-07 20:17:19.297 | import tooz.coordination
  2015-12-07 20:17:19.297 |   File 
"/home/jenkins/workspace/gate-ceilometer-python27/.tox/py27/local/lib/python2.7/site-packages/tooz/coordination.py",
 line 21, in 
  2015-12-07 20:17:19.297 | from oslo_utils import netutils
  2015-12-07 20:17:19.297 |   File 
"/home/jenkins/workspace/gate-ceilometer-python27/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/netutils.py",
 line 25, in 
  2015-12-07 20:17:19.297 | import netifaces
  2015-12-07 20:17:19.297 | ImportError: No module named netifaces

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1523716/+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 1495440] Re: bulk delete improvements

2015-12-15 Thread Armando Migliaccio
Based on discussion [1], let's go with option [1]. Let's limit this to
core resources only in the context of this effort.

[1]
http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-12-15-15.01.log.html

** Changed in: neutron
   Status: Triaged => Won't Fix

** Tags removed: rfe
** Tags added: rfe-approved

** Tags removed: api

** Changed in: neutron
 Assignee: Reedip (reedip-banerjee) => (unassigned)

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

Title:
  bulk delete improvements

Status in neutron:
  Won't Fix
Status in python-neutronclient:
  Triaged

Bug description:
  While trying to delete multiple firewall rule using CLI by passing
  firewall rule multiple times, it deletes only the first firewall Rule
  id

  stack@hdp-001:~$ neutron
  (neutron) firewall-rule-list
  
+--+-++-+-+
  | id   | name| firewall_policy_id 
| summary | enabled |
  
+--+-++-+-+
  | 8c4ea5c6-a6e4-43ab-a503-0a2265119238 | test1491637 |
| TCP,| True|
  |  | |
|  source: none(none),| |
  |  | |
|  dest: none(none),  | |
  |  | |
|  allow  | |
  | b8c1c061-8f92-482d-94d3-678f42c7ccd7 | rayrafw2|
| ICMP,   | True|
  |  | |
|  source: none(none),| |
  |  | |
|  dest: none(none),  | |
  |  | |
|  allow  | |
  | ba35dde7-8b07-4ba1-8338-496962c83dbc | testrule1491637 |
| UDP,| True|
  |  | |
|  source: 10.25.10.2/32(80), | |
  |  | |
|  dest: none(none),  | |
  |  | |
|  deny   | |
  
+--+-++-+-+
  (neutron) firewall-rule-delete 8c4ea5c6-a6e4-43ab-a503-0a2265119238 
b8c1c061-8f92-482d-94d3-678f42c7ccd7
  Deleted firewall_rule: 8c4ea5c6-a6e4-43ab-a503-0a2265119238
  (neutron) firewall-rule-list
  
+--+-++-+-+
  | id   | name| firewall_policy_id 
| summary | enabled |
  
+--+-++-+-+
  | b8c1c061-8f92-482d-94d3-678f42c7ccd7 | rayrafw2|
| ICMP,   | True|
  |  | |
|  source: none(none),| |
  |  | |
|  dest: none(none),  | |
  |  | |
|  allow  | |
  | ba35dde7-8b07-4ba1-8338-496962c83dbc | testrule1491637 |
| UDP,| True|
  |  | |
|  source: 10.25.10.2/32(80), | |
  |  | |
|  dest: none(none),  | |
  |  | |
|  deny   | |
  
+--+-++-+-+
  (neutron)

  It  will be better if we can delete multiple firewall rule by passing
  multiple firewall rule id

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1495440/+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   : 

[Yahoo-eng-team] [Bug 1516031] Re: Use of MD5 in OpenStack Glance image signature (CVE-2015-8234)

2015-12-15 Thread Nathan Kinder
This issue has been published as OSSN-0061:

  https://wiki.openstack.org/wiki/OSSN/OSSN-0061

** Changed in: ossn
   Status: New => Fix Released

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

Title:
  Use of MD5 in OpenStack Glance image signature (CVE-2015-8234)

Status in Glance:
  Triaged
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  This have been reported by Daniel P. Berrange:
  "
  In the OpenStack Liberty release, the Glance project added support for image 
signature verification.

  http://specs.openstack.org/openstack/glance-specs/specs/liberty/image-
  signing-and-verification-support.html

  The verification code was added in the following git commit

  
https://github.com/openstack/glance/commit/484ef1b40b738c87adb203bba6107ddb4b04ff6e

  
  Unfortunately the design of this signature verification method is flawed by 
design.

  The generalized approach to creating signatures of content is to apply
  a hash to the content and then encrypt it in some manner. Consider
  that the signature is defined to use hash=sha256 and cipher=rsa we can
  describe the signature computation as

  signature = rsa(sha256(content))

  In the case of verifying a disk image, the content we care about
  verifying is the complete disk image file. Unfortunately, the glance
  specification chose *not* to compute the signature against the disk
  image file. Glance already had an MD5 checksum calculated for the disk
  image file, so they instead chose to compute the signature against the
  MD5 checksum instead. ie glance is running

  signature = rsa(sha256(md5(disk-image-content)))

  This degrades the security of the system to that of the weakest hash,
  which is obviously MD5 here.

  The code where glance verifies the signature is in the
  glance/locations.py, the 'set_data' method where is does

   result = signature_utils.verify_signature(
   self.context, checksum, self.image.extra_properties)
   if result:
   LOG.info(_LI("Successfully verified signature for image %s"),
   self.image.image_id)

  The 'checksum' variable is populate by the glance_store driver, but it
  is hardcoded to always be md5 in all current glance storage backends:

   $ git grep hashlib glance_store/_drivers/ | grep checksum
   glance_store/_drivers/filesystem.py: checksum = hashlib.md5()
   glance_store/_drivers/rbd.py: checksum = hashlib.md5()
   glance_store/_drivers/s3.py: checksum = hashlib.md5()
   glance_store/_drivers/s3.py: checksum = hashlib.md5()
   glance_store/_drivers/sheepdog.py: checksum = hashlib.md5()
   glance_store/_drivers/swift/store.py: checksum =
   hashlib.md5()
   glance_store/_drivers/vmware_datastore.py: self.checksum =
   hashlib.md5()

  
  Since we will soon be shipping OpenStack Liberty release, we need to at least 
give a security notice to alert our customers to the fact that the signature 
verification is cryptographically weak/broken. IMHO, it quite likely deserves a 
CVE though

  NB, this is public knowledge as I first became aware of this flawed
  design in comments / discussion on a public specification proposed to
  implement the same approach in the Nova project.

  My suggested way to fix this is to simply abandon the current impl and
  re-do it such that it directly computes the signature against  the
  disk image, and does not use the existing md5 checksum in any way.

  Regards,
  Daniel
  "

  Mailing list thread for Nova impl: 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/079348.html
  Nova Spec: https://review.openstack.org/#/c/188874/

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1516031/+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 1504465] Re: neutron_lbaas.tests.tempest.v2.api.test_health_monitors_non_admin.TestHealthMonitors failed to clean up loadbalancer

2015-12-15 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/255017
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=f218929bc5126466b2a79b56d32e9cf042aa176d
Submitter: Jenkins
Branch:master

commit f218929bc5126466b2a79b56d32e9cf042aa176d
Author: Brandon Logan 
Date:   Tue Dec 8 18:24:28 2015 -0600

Force service provider relationships to load

A race condition was exposed in the LBaaS V2 db layer that was caused by a
hack to get around this issue.  The real issue is that since the
ProviderResourceAssociation is inserted independently, any models that were
created before this insert will not have their relationship with the
ProviderResourceAssocation loaded.  Using the session.expire_all method will
force the session to retrieve all new data and load this relationship for 
any
resource that uses this relationship.

Change-Id: I940b541f4ef9c489126cd2d215b1d857f0624de0
Closes-Bug: #1504465


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

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

Title:
  
neutron_lbaas.tests.tempest.v2.api.test_health_monitors_non_admin.TestHealthMonitors
  failed to clean up loadbalancer

Status in neutron:
  Fix Released

Bug description:
  http://logs.openstack.org/15/229915/3/gate/gate-neutron-lbaasv2-dsvm-
  minimal/5dc60be/logs/testr_results.html.gz

  ft1.2: tearDownClass 
(neutron_lbaas.tests.tempest.v2.api.test_health_monitors_non_admin.TestHealthMonitors)_StringException:
 Traceback (most recent call last):
File "neutron_lbaas/tests/tempest/lib/test.py", line 310, in tearDownClass
  six.reraise(etype, value, trace)
File "neutron_lbaas/tests/tempest/lib/test.py", line 293, in tearDownClass
  teardown()
File "neutron_lbaas/tests/tempest/v2/api/base.py", line 96, in 
resource_cleanup
  cls._try_delete_resource(cls._delete_load_balancer, lb_id)
File "neutron_lbaas/tests/tempest/v1/api/base.py", line 185, in 
_try_delete_resource
  delete_callable(*args, **kwargs)
File "neutron_lbaas/tests/tempest/v2/api/base.py", line 137, in 
_delete_load_balancer
  load_balancer_id, delete=True)
File "neutron_lbaas/tests/tempest/v2/api/base.py", line 160, in 
_wait_for_load_balancer_status
  load_balancer_id)
File "neutron_lbaas/tests/tempest/v2/clients/load_balancers_client.py", 
line 42, in get_load_balancer
  resp, body = self.get(url)
File 
"/usr/local/lib/python2.7/dist-packages/tempest_lib/common/rest_client.py", 
line 274, in get
  return self.request('GET', url, extra_headers, headers)
File 
"/usr/local/lib/python2.7/dist-packages/tempest_lib/common/rest_client.py", 
line 646, in request
  resp, resp_body)
File 
"/usr/local/lib/python2.7/dist-packages/tempest_lib/common/rest_client.py", 
line 760, in _error_checker
  message=message)
  tempest_lib.exceptions.ServerFault: Got server fault
  Details: Request Failed: internal server error while processing your request.

  
  Server failure is:

  2015-10-08 23:22:56.409 ERROR neutron.api.v2.resource 
[req-fafd7f88-2e1a-41ce-85c1-9dbacc6f1d93 TestHealthMonitors-867400801 
TestHealthMonitors-1196952833] show failed
  2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource Traceback (most 
recent call last):
  2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/api/v2/resource.py", line 83, in resource
  2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource result = 
method(request=request, **args)
  2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/api/v2/base.py", line 359, in show
  2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource 
parent_id=parent_id),
  2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/api/v2/base.py", line 311, in _item
  2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource obj = 
obj_getter(request.context, id, **kwargs)
  2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron-lbaas/neutron_lbaas/services/loadbalancer/plugin.py", 
line 560, in get_loadbalancer
  2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource return 
self.db.get_loadbalancer(context, id).to_api_dict()
  2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron-lbaas/neutron_lbaas/db/loadbalancer/loadbalancer_dbv2.py",
 line 268, in get_loadbalancer
  2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource lb_db = 
self._get_resource(context, models.LoadBalancer, id)
  2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron-lbaas/neutron_lbaas/db/loadbalancer/loadbalancer_dbv2.py",
 line 73, in _get_resource
  2015-10-08 23:22:56.409 13383 

[Yahoo-eng-team] [Bug 1175686] Re: Documentation doesn't explain how to install virtualenv

2015-12-15 Thread OpenStack Infra
Fix proposed to branch: master
Review: https://review.openstack.org/258188

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

** Changed in: keystone
 Assignee: Raildo Mascena de Sousa Filho (raildo) => John Dewey (retr0h)

-- 
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/1175686

Title:
  Documentation doesn't explain how to install virtualenv

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  In the page "Setting up a Keystone development environment"
  (http://docs.openstack.org/developer/keystone/setup.html), the section
  "Installing dependencies",  the subsection "PyPi Packages and
  VirtualEnv" recommends to set up a virtual environment. However, it
  doesn't explain how to set it up:

  edu@petra:~/OpenStack/keystone$ python tools/install_venv.py 
  ERROR: virtualenv not found.

  Keystone development requires virtualenv, please install it using your
  favorite package management tool

  The following package is required:

  sudo apt-get install python-virtualenv

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1175686/+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 1522732] Re: Add availability_zone support for router

2015-12-15 Thread Henry Gessau
** Also affects: openstack-manuals
   Importance: Undecided
   Status: New

** Changed in: neutron
   Status: New => Fix Released

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

Title:
  Add availability_zone support for router

Status in neutron:
  Fix Released
Status in openstack-manuals:
  New

Bug description:
  https://review.openstack.org/224418
  \Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit ef2a5543cc7e15769031f81c921d4babb7e14d04
  Author: Hirofumi Ichihara 
  Date:   Thu Dec 3 14:12:19 2015 +0900

  Add availability_zone support for router
  
  This patch adds the availability_zone support for router.
  
  APIImpact
  DocImpact: Make router scheduler availability zone aware. If multiple
  availability zones are used, set router_scheduler_driver =
  neutron.scheduler.l3_agent_scheduler.AZLeastRoutersScheduler. This 
scheduler
  selects agent depends on LeastRoutersScheduler logic within an 
availability
  zone so that considers the weight of agent.
  
  Change-Id: Id26d9494b9a5b459767e93a850f47a3b014b11bb
  Co-Authored-By: IWAMOTO Toshihiro 
  Partially-implements: blueprint add-availability-zone

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1522732/+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 1405077] Re: Provide API to manage segmentation ranges

2015-12-15 Thread Armando Migliaccio
Discussion [1] was not really conclusive, but we should look into
providing/refining a mechanism to reload config options via oslo.service
primitives and without API interruption. As commented before, we already
have some integration in place and more can be done, but it can be done
in the context of as separate individual bug fixes.

As for what we currently have captured in config options, I'd say let's
draw a line in the sand and assume that from here on out we consider
more carefully whether certain options are really meant to be statically
or manually configured, taking into consideration how often these
configs may change throughout the life cycle of the system, and whether
they apply across the entire set of plugins that integrate with Neutron.

For this reason, I think it's fair to say that this proposal should be
marked as "won't fix", because a) vlan range is a plugin/deployment
specific config option, and b) with small fixes, it can be reloaded
without API interruption, that can be supported via sys management
tools.

[1]
http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-12-15-15.01.log.html

** Changed in: neutron
   Status: Triaged => Won't Fix

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

Title:
  Provide API to manage segmentation ranges

Status in neutron:
  Won't Fix

Bug description:
  This bug was reported like this:

  I changed network_vlan_ranges configuration in configuration file, and I want 
changes to take effect without restarting the neutron server.
  It may not be a bug, but restarting the networking service itself could lead 
to some critical processes to stop temporarily.

  As some configurations are subjected to change often, automatic
  reloading of configurations without restarting the whole service may
  be a feasible solution.

  However, I think what this is asking for is this:

  As an administrator I would like to edit my segmentation range via an
  API (for vlan that would be network_vlan_ranges, vni_ranges for
  geneve/vxlan, and tunnel_id_ranges for gre), instead of editing the
  file in place. It would be beneficial for the admin, because if I run
  out of my range whilst my deployment is up and running I don't want to
  cause an operational downtime to expand it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1405077/+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 1518087] Re: [RFE] Method to guarantee that at least one mechanism driver implements security groups

2015-12-15 Thread Armando Migliaccio
Based on discussion [1], we ruled out against of this. Can be revised if
justification for rejection is disputed based on other grounds.

[1]
http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-12-08-15.03.log.html

** Changed in: neutron
   Status: Triaged => Won't Fix

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

Title:
  [RFE] Method to guarantee that at least one mechanism driver
  implements security groups

Status in neutron:
  Won't Fix

Bug description:
  Now we can't get info that MD support SGs or not, and no way to
  guarantee that at least one MD will be responsible to handle the
  security group event.

  And probably other extension like QOS, have the similar problem.

  more info could be find here
  https://review.openstack.org/#/c/240356/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1518087/+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 1506566] Re: no notifications from Neutron in Ceilometer

2015-12-15 Thread Launchpad Bug Tracker
[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
   Status: Incomplete => Expired

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

Title:
  no notifications from Neutron in Ceilometer

Status in neutron:
  Expired

Bug description:
  I've deployed devstack using the following local.conf (with
  Ceilometer) - http://paste.openstack.org/show/476407/ (master branch)

  After deployment I tried to check Ceilometer notifications and get
  nothing from Neutron. For example, I created a router and then
  executed ceilometer sample-list -m router.create  -l10 - got nothing.

  Is something misconfigured? Also there's no information from Neutron
  metering agent regarding bandwidth.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1506566/+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 1506567] Re: No information from Neutron Metering agent

2015-12-15 Thread Launchpad Bug Tracker
[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
   Status: Incomplete => Expired

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

Title:
  No information from Neutron Metering agent

Status in neutron:
  Expired

Bug description:
  I deployed OpenStack cloud with stable/kilo code - a controller/network node 
and a compute node (Ubuntu 14.04). I have Metering agent enabled and configured 
 as follows:
  driver = 
neutron.services.metering.drivers.iptables.iptables_driver.IptablesMeteringDriver
  interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver

  When I try to check information from it in Ceilometer, I always get
  zero. e.x.:

  root@node-1:~# ceilometer sample-list -m bandwidth  -l10
  
+--+---+---++--++
  | Resource ID  | Name  | Type  | Volume | Unit | 
Timestamp  |
  
+--+---+---++--++
  | 66fab4a9-aefe-4534-b8a3-b0c0db9edf82 | bandwidth | delta | 0.0| B| 
2015-10-15T16:55:26.766000 |

  Is it expected? I spawned two VMs and tried to pass some traffic
  between them using iperf, but still no results

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1506567/+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 1526607] [NEW] refactor test_attributes.py

2015-12-15 Thread Bo Chi
Public bug reported:

there're many test methods contains repeated test cases, such as

def test_validate_string(self):
msg = attributes._validate_string(None, None)
self.assertEqual("'None' is not a valid string", msg)
   
# 0 == len(data) == max_len
msg = attributes._validate_string("", 0) 
self.assertIsNone(msg)
   
# 0 == len(data) < max_len
msg = attributes._validate_string("", 9) 
self.assertIsNone(msg)
   
# 0 < len(data) < max_len
msg = attributes._validate_string("123456789", 10)
self.assertIsNone(msg)
   
# 0 < len(data) == max_len
msg = attributes._validate_string("123456789", 9)
self.assertIsNone(msg)
   
# 0 < max_len < len(data)
msg = attributes._validate_string("1234567890", 9)
self.assertEqual("'1234567890' exceeds maximum length of 9", msg)
   
msg = attributes._validate_string("123456789", None)
self.assertIsNone(msg) 

we can refactor this with a for loop, to make them look better

** Affects: neutron
 Importance: Undecided
 Assignee: Bo Chi (bochi-michael)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Bo Chi (bochi-michael)

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

Title:
  refactor test_attributes.py

Status in neutron:
  New

Bug description:
  there're many test methods contains repeated test cases, such as

  def test_validate_string(self):
  msg = attributes._validate_string(None, None)
  self.assertEqual("'None' is not a valid string", msg)
 
  # 0 == len(data) == max_len
  msg = attributes._validate_string("", 0) 
  self.assertIsNone(msg)
 
  # 0 == len(data) < max_len
  msg = attributes._validate_string("", 9) 
  self.assertIsNone(msg)
 
  # 0 < len(data) < max_len
  msg = attributes._validate_string("123456789", 10)
  self.assertIsNone(msg)
 
  # 0 < len(data) == max_len
  msg = attributes._validate_string("123456789", 9)
  self.assertIsNone(msg)
 
  # 0 < max_len < len(data)
  msg = attributes._validate_string("1234567890", 9)
  self.assertEqual("'1234567890' exceeds maximum length of 9", msg)
 
  msg = attributes._validate_string("123456789", None)
  self.assertIsNone(msg) 

  we can refactor this with a for loop, to make them look better

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1526607/+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 1523968] Re: LBaaS v2 - LB update with admin-state-down fails

2015-12-15 Thread Reedip
This is not a neutron issue, but a neutronclient side fix, as admin-
state-down is not required during Update in any CLI

** Project changed: neutron => python-neutronclient

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

Title:
  LBaaS v2 - LB update with admin-state-down fails

Status in python-neutronclient:
  New

Bug description:
  Updating loadbalancer instance with admin-state-down fails

  
  CLI Command:
  neutron lbaas-loadbalancer-update --admin-state-down NFV_LB

  Output:
  Unrecognized attribute(s) 'admin_state_down'

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-neutronclient/+bug/1523968/+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 1490804] Re: PKI Token Revocation Bypass (CVE-2015-7546)

2015-12-15 Thread Nathan Kinder
This issue has been published as OSSN-0062:

  https://wiki.openstack.org/wiki/OSSN/OSSN-0062

** Changed in: ossn
   Status: New => Fix Released

-- 
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/1490804

Title:
  PKI Token Revocation Bypass (CVE-2015-7546)

Status in django-openstack-auth:
  Invalid
Status in OpenStack Identity (keystone):
  In Progress
Status in keystonemiddleware:
  In Progress
Status in OpenStack Security Advisory:
  Incomplete
Status in OpenStack Security Notes:
  Fix Released
Status in python-keystoneclient:
  Won't Fix

Bug description:
  A keystone token which has been revoked can still be used by manipulating 
particular byte fields within the token.
  When a Keystone token is revoked it is added to the revoked list which stores 
the exact token value. Any API will look at the token to see whether or not it 
should accept a token. By changing a single byte within the token, the 
revocation can be bypassed.  see the testing script [1].

  It is suggested that the revocation should be changed to only check
  the token's inner ID.

  [1] http://paste.openstack.org/show/436516/

To manage notifications about this bug go to:
https://bugs.launchpad.net/django-openstack-auth/+bug/1490804/+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 1490497] Re: pep8-incompliant filenames missing in gate console logs

2015-12-15 Thread Launchpad Bug Tracker
[Expired for hacking because there has been no activity for 60 days.]

** Changed in: hacking
   Status: Incomplete => Expired

-- 
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/1490497

Title:
  pep8-incompliant filenames missing in gate console logs

Status in hacking:
  Expired
Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  Jenkins reported gate-keystone-pep8 failure on patch set 12 @ 
https://review.openstack.org/#/c/209524/  .
  But the console logs didn't contain the filenames that are incompliant with 
pep8.
  
http://logs.openstack.org/24/209524/12/check/gate-keystone-pep8/b2b7500/console.html
  
  ...
  2015-08-30 22:34:11.101 | pep8 runtests: PYTHONHASHSEED='3894393079'
  2015-08-30 22:34:11.102 | pep8 runtests: commands[0] | flake8
  2015-08-30 22:34:11.102 |   /home/jenkins/workspace/gate-keystone-pep8$ 
/home/jenkins/workspace/gate-keystone-pep8/.tox/pep8/bin/flake8 
  2015-08-30 22:34:16.619 | ERROR: InvocationError: 
'/home/jenkins/workspace/gate-keystone-pep8/.tox/pep8/bin/flake8'
  2015-08-30 22:34:16.620 | ___ summary 

  2015-08-30 22:34:16.620 | ERROR:   pep8: commands failed
  ...
  

  Typically, it contains the filenames as well.
  Eg. Console logs pf patchset 1 contains the filenames.
  
http://logs.openstack.org/24/209524/1/check/gate-keystone-pep8/19f2885/console.html
  
  ...
  2015-08-05 14:45:15.247 | pep8 runtests: PYTHONHASHSEED='1879982710'
  2015-08-05 14:45:15.247 | pep8 runtests: commands[0] | flake8
  2015-08-05 14:45:15.247 |   /home/jenkins/workspace/gate-keystone-pep8$ 
/home/jenkins/workspace/gate-keystone-pep8/.tox/pep8/bin/flake8 
  2015-08-05 14:45:20.518 | ./keystone/assignment/backends/ldap.py:37:5: E301 
expected 1 blank line, found 0
  2015-08-05 14:45:20.518 | @versionutils.deprecated(
  2015-08-05 14:45:20.518 | ^
  ...
  2015-08-05 14:45:20.872 | ERROR: InvocationError: 
'/home/jenkins/workspace/gate-keystone-pep8/.tox/pep8/bin/flake8'
  2015-08-05 14:45:20.872 | ___ summary 

  2015-08-05 14:45:20.873 | ERROR:   pep8: commands failed
  ...
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/hacking/+bug/1490497/+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 1526611] [NEW] integration test timeout on every run

2015-12-15 Thread Richard Jones
Public bug reported:

While attempting to run the integration test suite locally on my OS X
system against a remote devstack I repeatable encountered the following
timeout:

_StringException: Traceback (most recent call last):
  File 
".../src/openstack/horizon/openstack_dashboard/test/integration_tests/tests/test_login.py",
 line 25, in test_login
login_pg.go_to_login_page()
  File 
".../src/openstack/horizon/openstack_dashboard/test/integration_tests/pages/pageobject.py",
 line 79, in go_to_login_page
self.driver.get(self.login_url)
  File 
".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py",
 line 213, in get
self.execute(Command.GET, url': url})
  File 
".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py",
 line 199, in execute
response = self.command_executor.execute(driver_command, params)
  File 
".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/remote_connection.py",
 line 395, in execute
return self._request(command_info[0], url, body=data)
  File 
".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/remote_connection.py",
 line 426, in _request
resp = self._conn.getresponse()
  File ".../.pyenv/versions/2.7.9/lib/python2.7/httplib.py", line 1073, in 
getresponse
response.begin()
  File ".../.pyenv/versions/2.7.9/lib/python2.7/httplib.py", line 415, in begin
version, status, reason = self._read_status()
  File ".../.pyenv/versions/2.7.9/lib/python2.7/httplib.py", line 371, in 
_read_status
line = self.fp.readline(_MAXLINE + 1)
  File ".../.pyenv/versions/2.7.9/lib/python2.7/socket.py", line 476, in 
readline
data = self._sock.recv(self._rbufsize)
socket.timeout: timed out

This is in the communication channel between the test process and the
selenium webdriver process. I get it every time I attempt to run a test.

** Affects: horizon
 Importance: Undecided
 Status: New

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

Title:
  integration test timeout on every run

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  While attempting to run the integration test suite locally on my OS X
  system against a remote devstack I repeatable encountered the
  following timeout:

  _StringException: Traceback (most recent call last):
File 
".../src/openstack/horizon/openstack_dashboard/test/integration_tests/tests/test_login.py",
 line 25, in test_login
  login_pg.go_to_login_page()
File 
".../src/openstack/horizon/openstack_dashboard/test/integration_tests/pages/pageobject.py",
 line 79, in go_to_login_page
  self.driver.get(self.login_url)
File 
".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py",
 line 213, in get
  self.execute(Command.GET, url': url})
File 
".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py",
 line 199, in execute
  response = self.command_executor.execute(driver_command, params)
File 
".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/remote_connection.py",
 line 395, in execute
  return self._request(command_info[0], url, body=data)
File 
".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/remote_connection.py",
 line 426, in _request
  resp = self._conn.getresponse()
File ".../.pyenv/versions/2.7.9/lib/python2.7/httplib.py", line 1073, in 
getresponse
  response.begin()
File ".../.pyenv/versions/2.7.9/lib/python2.7/httplib.py", line 415, in 
begin
  version, status, reason = self._read_status()
File ".../.pyenv/versions/2.7.9/lib/python2.7/httplib.py", line 371, in 
_read_status
  line = self.fp.readline(_MAXLINE + 1)
File ".../.pyenv/versions/2.7.9/lib/python2.7/socket.py", line 476, in 
readline
  data = self._sock.recv(self._rbufsize)
  socket.timeout: timed out

  This is in the communication channel between the test process and the
  selenium webdriver process. I get it every time I attempt to run a
  test.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1526611/+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 1370037] Re: bulk termination of instances

2015-12-15 Thread Matthias Runge
** Changed in: horizon
   Status: New => Invalid

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

Title:
  bulk termination of instances

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  while terminating a bulk of instances from the horizon, the first
  instance termination failed, the other instances all stayed in
  available status.

  Steps to Reproduce:
  1. Delete a bulk of instances
  2. The first deletion process should fail & the instance status should turn 
to Error

  Actual results:
  The other instances are not been terminated

  Expected results:
  The termination of the instances should continue to the other instances

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1370037/+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 1462694] Re: python keystone v3 client RoleAssignmentManager needs to pass include_subtree

2015-12-15 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/188184
Committed: 
https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=7ff3955665b64e59db8bf1668ae5d7839bb6b730
Submitter: Jenkins
Branch:master

commit 7ff3955665b64e59db8bf1668ae5d7839bb6b730
Author: daniel-a-nguyen 
Date:   Wed Jun 3 14:39:34 2015 -0700

Add include_subtree to role_list_assignments call

This is needed for Domain Admin to list role assignments.

Related-Bug: 1437407
Depends-On: I3495c7cab3b40811b2722ac7d70ddda30410b62b

Closes-Bug: #1462694
Change-Id: I63849d5f39d090fec3ef6b9182f339e198e0c551


** Changed in: python-keystoneclient
   Status: In Progress => Fix Released

-- 
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/1462694

Title:
  python keystone v3 client RoleAssignmentManager  needs to  pass
  include_subtree

Status in OpenStack Identity (keystone):
  Invalid
Status in python-keystoneclient:
  Fix Released

Bug description:
  In order for a Domain Admin to successfully list the role assignments
  in the v3 api we need to pass a new request parameter to the api.
  Horizon depends on this for domain support.

  The call looks like this

   GET /v3/role_assignments?scope.domain.id=id_subtree

  and the results will return all the project role_assignments for the domain 
id.
  This can be further filters by project id in the client code.

  This is related to https://bugs.launchpad.net/keystone/+bug/1437407

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1462694/+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 1526599] [NEW] back-port of oslo import to stable kilo is not enough

2015-12-15 Thread watanabe.isao
Public bug reported:

Back-port of oslo import to stable kilo is not enough and caused
Devstack installation failed.

[Error message example]
2015-12-16 02:41:08.120 | + cd /opt/stack/horizon
2015-12-16 02:41:08.120 | + ./run_tests.sh -N --compilemessages
2015-12-16 02:41:08.604 | WARNING:root:No local_settings file found.
2015-12-16 02:41:09.019 | Traceback (most recent call last):
2015-12-16 02:41:09.019 |   File "/opt/stack/horizon/manage.py", line 23, in 

2015-12-16 02:41:09.019 | execute_from_command_line(sys.argv)
2015-12-16 02:41:09.019 |   File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 354, in execute_from_command_line
2015-12-16 02:41:09.020 | utility.execute()
2015-12-16 02:41:09.020 |   File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 303, in execute
2015-12-16 02:41:09.020 | settings.INSTALLED_APPS
2015-12-16 02:41:09.020 |   File 
"/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 48, in 
__getattr__
2015-12-16 02:41:09.020 | self._setup(name)
2015-12-16 02:41:09.020 |   File 
"/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 44, in 
_setup
2015-12-16 02:41:09.020 | self._wrapped = Settings(settings_module)
2015-12-16 02:41:09.020 |   File 
"/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 92, in 
__init__
2015-12-16 02:41:09.021 | mod = 
importlib.import_module(self.SETTINGS_MODULE)
2015-12-16 02:41:09.021 |   File "/usr/lib/python2.7/importlib/__init__.py", 
line 37, in import_module
2015-12-16 02:41:09.021 | __import__(name)
2015-12-16 02:41:09.021 |   File 
"/opt/stack/horizon/openstack_dashboard/settings.py", line 313, in 
2015-12-16 02:41:09.021 | from openstack_dashboard import policy_backend
2015-12-16 02:41:09.021 |   File 
"/opt/stack/horizon/openstack_dashboard/policy_backend.py", line 23, in 
2015-12-16 02:41:09.021 | from openstack_dashboard.openstack.common import 
policy
2015-12-16 02:41:09.021 |   File 
"/opt/stack/horizon/openstack_dashboard/openstack/common/policy.py", line 83, 
in 
2015-12-16 02:41:09.021 | from oslo.config import cfg
2015-12-16 02:41:09.022 | ImportError: No module named config

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: kilo-backport-potential

-- 
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/1526599

Title:
  back-port of oslo import to stable kilo is not enough

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Back-port of oslo import to stable kilo is not enough and caused
  Devstack installation failed.

  [Error message example]
  2015-12-16 02:41:08.120 | + cd /opt/stack/horizon
  2015-12-16 02:41:08.120 | + ./run_tests.sh -N --compilemessages
  2015-12-16 02:41:08.604 | WARNING:root:No local_settings file found.
  2015-12-16 02:41:09.019 | Traceback (most recent call last):
  2015-12-16 02:41:09.019 |   File "/opt/stack/horizon/manage.py", line 23, in 

  2015-12-16 02:41:09.019 | execute_from_command_line(sys.argv)
  2015-12-16 02:41:09.019 |   File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 354, in execute_from_command_line
  2015-12-16 02:41:09.020 | utility.execute()
  2015-12-16 02:41:09.020 |   File 
"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 303, in execute
  2015-12-16 02:41:09.020 | settings.INSTALLED_APPS
  2015-12-16 02:41:09.020 |   File 
"/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 48, in 
__getattr__
  2015-12-16 02:41:09.020 | self._setup(name)
  2015-12-16 02:41:09.020 |   File 
"/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 44, in 
_setup
  2015-12-16 02:41:09.020 | self._wrapped = Settings(settings_module)
  2015-12-16 02:41:09.020 |   File 
"/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 92, in 
__init__
  2015-12-16 02:41:09.021 | mod = 
importlib.import_module(self.SETTINGS_MODULE)
  2015-12-16 02:41:09.021 |   File "/usr/lib/python2.7/importlib/__init__.py", 
line 37, in import_module
  2015-12-16 02:41:09.021 | __import__(name)
  2015-12-16 02:41:09.021 |   File 
"/opt/stack/horizon/openstack_dashboard/settings.py", line 313, in 
  2015-12-16 02:41:09.021 | from openstack_dashboard import policy_backend
  2015-12-16 02:41:09.021 |   File 
"/opt/stack/horizon/openstack_dashboard/policy_backend.py", line 23, in 
  2015-12-16 02:41:09.021 | from openstack_dashboard.openstack.common 
import policy
  2015-12-16 02:41:09.021 |   File 
"/opt/stack/horizon/openstack_dashboard/openstack/common/policy.py", line 83, 
in 
  2015-12-16 02:41:09.021 | from oslo.config import cfg
  2015-12-16 02:41:09.022 | ImportError: No module named config

To manage notifications about this bug go to:

[Yahoo-eng-team] [Bug 968696] Re: "admin"-ness not properly scoped

2015-12-15 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/240720
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=9804081a80ef815a86407a64f967986a7bf9ba25
Submitter: Jenkins
Branch:master

commit 9804081a80ef815a86407a64f967986a7bf9ba25
Author: Adam Young 
Date:   Sun Nov 1 11:55:45 2015 -0500

Updated Cloudsample

Uses configuration options to determine if a token is for the admin
project and should be granted admin privileges.

Closes-Bug: 968696

Change-Id: Ib23452e171dc90115c77fa5a4b9dc4649054eb0e


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

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

Title:
  "admin"-ness not properly scoped

Status in Cinder:
  Fix Released
Status in Glance:
  New
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Triaged
Status in OpenStack Compute (nova):
  Confirmed
Status in puppet-keystone:
  New

Bug description:
  Fact: Keystone's rbac model grants roles to users on specific tenants,
  and post-keystone redux, there are no longer "global" roles.

  Problem: Granting a user an "admin" role on ANY tenant grants them
  unlimited "admin"-ness throughout the system because there is no
  differentiation between a scoped "admin"-ness and a global
  "admin"-ness.

  I don't have a specific solution to advocate, but being an admin on
  *any* tenant simply *cannot* allow you to administer all of keystone.

  Steps to reproduce (from Horizon, though you could do this with the
  CLI, too):

  1. User A (existing admin) creates Project B and User B.
  2. User A adds User B to Project B with the admin role on Project B.
  3. User B logs in and now has unlimited admin rights not only to view things 
in the dashboard, but to take actions like creating new projects and users, 
managing existing projects and users, etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/968696/+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 1424096] Re: DVR routers attached to shared networks aren't being unscheduled from a compute node after deleting the VMs using the shared net

2015-12-15 Thread Oleg Bondarev
I faced the bug while reworking unit tests into functional tests: when 
performing steps described in the description I get:
 2015-12-15 17:41:23,484ERROR [neutron.callbacks.manager] Error during 
notification for neutron.db.l3_dvrscheduler_db._notify_port_delete port, 
after_delete
Traceback (most recent call last):
  File "neutron/callbacks/manager.py", line 141, in _notify_loop
callback(resource, event, trigger, **kwargs)
  File "neutron/db/l3_dvrscheduler_db.py", line 485, in _notify_port_delete
context, router['agent_id'], router['router_id'])
  File "neutron/db/l3_dvrscheduler_db.py", line 439, in 
remove_router_from_l3_agent
router = self.get_router(context, router_id)
  File "neutron/db/l3_db.py", line 451, in get_router
router = self._get_router(context, id)
  File "neutron/db/l3_db.py", line 137, in _get_router
raise l3.RouterNotFound(router_id=router_id)
RouterNotFound: Router 7d52836b-8fe5-4417-842f-3cbe0920c89c could not be 
found

and router is not removed from host which has no more dvr serviceable
ports.

Looks like we also need admin context in order to remove admin router
from a host when non-admin tenant removes last dvr serviceable port on a
shared network.

** Changed in: neutron
   Status: Fix Released => Confirmed

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

Title:
  DVR routers attached to shared networks aren't being unscheduled from
  a compute node after deleting the VMs using the shared net

Status in neutron:
  Confirmed
Status in neutron juno series:
  Fix Released
Status in neutron kilo series:
  New

Bug description:
  As the administrator, a DVR router is created and attached to a shared
  network. The administrator also created the shared network.

  As a non-admin tenant, a VM is created with the port using the shared
  network.  The only VM using the shared network is scheduled to a
  compute node.  When the VM is deleted, it is expected the qrouter
  namespace of the DVR router is removed.  But it is not.  This doesn't
  happen with routers attached to networks that are not shared.

  The environment consists of 1 controller node and 1 compute node.

  Routers having the problem are created by the administrator attached
  to shared networks that are also owned by the admin:

  As the administrator, do the following commands on a setup having 1
  compute node and 1 controller node:

  1. neutron net-create shared-net -- --shared True
 Shared net's uuid is f9ccf1f9-aea9-4f72-accc-8a03170fa242.

  2. neutron subnet-create --name shared-subnet shared-net 10.0.0.0/16

  3. neutron router-create shared-router
  Router's UUID is ab78428a-9653-4a7b-98ec-22e1f956f44f.

  4. neutron router-interface-add shared-router shared-subnet
  5. neutron router-gateway-set  shared-router public

  
  As a non-admin tenant (tenant-id: 95cd5d9c61cf45c7bdd4e9ee52659d13), boot a 
VM using the shared-net network:

  1. neutron net-show shared-net
  +-+--+
  | Field   | Value|
  +-+--+
  | admin_state_up  | True |
  | id  | f9ccf1f9-aea9-4f72-accc-8a03170fa242 |
  | name| shared-net   |
  | router:external | False|
  | shared  | True |
  | status  | ACTIVE   |
  | subnets | c4fd4279-81a7-40d6-a80b-01e8238c1c2d |
  | tenant_id   | 2a54d6758fab47f4a2508b06284b5104 |
  +-+--+

  At this point, there are no VMs using the shared-net network running
  in the environment.

  2. Boot a VM that uses the shared-net network: nova boot ... --nic 
net-id=f9ccf1f9-aea9-4f72-accc-8a03170fa242 ... vm_sharednet
  3. Assign a floating IP to the VM "vm_sharednet"
  4. Delete "vm_sharednet". On the compute node, the qrouter namespace of the 
shared router (qrouter-ab78428a-9653-4a7b-98ec-22e1f956f44f) is left behind

  stack@DVR-CN2:~/DEVSTACK/manage$ ip netns
  qrouter-ab78428a-9653-4a7b-98ec-22e1f956f44f
   ...

  
  This is consistent with the output of "neutron l3-agent-list-hosting-router" 
command.  It shows the router is still being hosted on the compute node.

  
  $ neutron l3-agent-list-hosting-router ab78428a-9653-4a7b-98ec-22e1f956f44f
  
+--+++---+
  | id   | host   | admin_state_up | 
alive |
  
+--+++---+
  | 42f12eb0-51bc-4861-928a-48de51ba7ae1 | DVR-Controller | True   | 
:-)   |
  | 

[Yahoo-eng-team] [Bug 1522199] Re: Functional test_ipwrapper_get_device_by_ip fails with new kernels

2015-12-15 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/254801
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=8ddeb4be9e32e5cefab8324d0cbf9cecead1f808
Submitter: Jenkins
Branch:master

commit 8ddeb4be9e32e5cefab8324d0cbf9cecead1f808
Author: John Schwarz 
Date:   Tue Dec 8 16:17:46 2015 +0200

Ignore possible suffix in iproute commands.

Closes-Bug: #1522199
Change-Id: I14815abd9345edb079e3331cbe2465ad22a0d4c3


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

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

Title:
  Functional test_ipwrapper_get_device_by_ip fails with new kernels

Status in neutron:
  Fix Released

Bug description:
  Trace:
  http://paste.openstack.org/show/480710/

  The test creates a device via:
  sudo ip tuntap add test223ef12 mode tap

  Which on my system (Fedora 22) results in a device called:
  test223ef12@NONE

  And the test fails to compare 'test223ef12' to 'test223ef12@NONE'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1522199/+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 1526577] [NEW] Wrong Allocation Pools will disable the 'Next' button

2015-12-15 Thread Fei Long Wang
Public bug reported:

When create a new network, if user give a wrong Allocation Pools by
typo, then user will get an error. And the 'Create' button turned to be
'Next' button and in disabled mode. However, at that moment, even user
fix the wrong pools, user will still have to go back instead of let the
user try again at current page.

** Affects: horizon
 Importance: Undecided
 Status: New

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

Title:
  Wrong Allocation Pools will disable the 'Next' button

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  When create a new network, if user give a wrong Allocation Pools by
  typo, then user will get an error. And the 'Create' button turned to
  be 'Next' button and in disabled mode. However, at that moment, even
  user fix the wrong pools, user will still have to go back instead of
  let the user try again at current page.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1526577/+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 1526587] [NEW] Neutron doesn't have a command to show the available ports for one subnet

2015-12-15 Thread carl
Public bug reported:

Neutron doesn't have a command to show the available ports for one
subnet.

We can get the available port list with command:
[root@cts-orch ~]# neutron port-list | grep `neutron subnet-show 110-OAM2 | awk 
'/ id / {print $4}'` | cut -d"|" -f5 | cut -d":" -f3 | sort
 "135.111.122.97"}
 "135.111.122.98"}

But we don't have a command to show the available ports for one subnet.
I write a shell script to show the available ports as below, but it will
be helpful if we can provide such a neutron command.

[root@cts-orch ~]# ./show_available_ip.sh 110-OAM2
135.111.122.99
135.111.122.100
135.111.122.101
135.111.122.102
135.111.122.103
135.111.122.104
135.111.122.105
135.111.122.106
135.111.122.107
135.111.122.108
135.111.122.109
135.111.122.110
135.111.122.111
135.111.122.112
135.111.122.113
135.111.122.114
135.111.122.115
135.111.122.116
135.111.122.117
135.111.122.118
135.111.122.119
135.111.122.120
135.111.122.121
135.111.122.122
135.111.122.123
135.111.122.124
Total Count: 26

** 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/1526587

Title:
  Neutron doesn't have a command to show the available ports for one
  subnet

Status in neutron:
  New

Bug description:
  Neutron doesn't have a command to show the available ports for one
  subnet.

  We can get the available port list with command:
  [root@cts-orch ~]# neutron port-list | grep `neutron subnet-show 110-OAM2 | 
awk '/ id / {print $4}'` | cut -d"|" -f5 | cut -d":" -f3 | sort
   "135.111.122.97"}
   "135.111.122.98"}

  But we don't have a command to show the available ports for one
  subnet. I write a shell script to show the available ports as below,
  but it will be helpful if we can provide such a neutron command.

  [root@cts-orch ~]# ./show_available_ip.sh 110-OAM2
  135.111.122.99
  135.111.122.100
  135.111.122.101
  135.111.122.102
  135.111.122.103
  135.111.122.104
  135.111.122.105
  135.111.122.106
  135.111.122.107
  135.111.122.108
  135.111.122.109
  135.111.122.110
  135.111.122.111
  135.111.122.112
  135.111.122.113
  135.111.122.114
  135.111.122.115
  135.111.122.116
  135.111.122.117
  135.111.122.118
  135.111.122.119
  135.111.122.120
  135.111.122.121
  135.111.122.122
  135.111.122.123
  135.111.122.124
  Total Count: 26

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1526587/+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 1526620] [NEW] host names are different even if scheduling servers on the same host

2015-12-15 Thread Ken'ichi Ohmichi
Public bug reported:

Even if creating a server with scheduler_hint: same_host, the server is
created on different host on the gate.

'OS-EXT-SRV-ATTR:host' value of "show a server" API is different between
servers like:

 * ubuntu-trusty-2-node-rax-iad-6591881
 * ubuntu-trusty-2-node-rax-iad-6591881-77157

Now we are trying to add Tempest test for verifying the scheduler_hint on 
https://review.openstack.org/#/c/257660
However the test cannot be passed due to this problem.

** 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/1526620

Title:
  host names are different even if scheduling servers on the same host

Status in OpenStack Compute (nova):
  New

Bug description:
  Even if creating a server with scheduler_hint: same_host, the server
  is created on different host on the gate.

  'OS-EXT-SRV-ATTR:host' value of "show a server" API is different
  between servers like:

   * ubuntu-trusty-2-node-rax-iad-6591881
   * ubuntu-trusty-2-node-rax-iad-6591881-77157

  Now we are trying to add Tempest test for verifying the scheduler_hint on 
https://review.openstack.org/#/c/257660
  However the test cannot be passed due to this problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1526620/+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 1526630] [NEW] Unexpected API Error returned when boot an instance with an wrong octal ip address as v4-fixed-ip

2015-12-15 Thread ibm-cloud-qa
Public bug reported:

[Summary]
Unexpected API Error returned when boot an instance with an wrong octal ip 
address as v4-fixed-ip

[Topo]
devstack all-in-one node

[Description and expect result]
no Unexpected API Error, should return an error says that "Invalid input for 
field/attribute fixed_ip"

[Reproduceable or not]
reproduceable 

[Recreate Steps]
1) create a network/subnet:
root@45-59:/opt/stack/devstack# neutron net-list | grep net2
| 2de63c95-f645-492c-9197-5d4d5244a8ba | net2| 
47eb5e03-c16a-4303-923c-21a061f2909e 1.0.0.0/24  |
root@45-59:/opt/stack/devstack# 


2) launch an instance with an wrong octal ip address as v4-fixed-ip, Unexpected 
API Error returned:   ISSUE
root@45-59:/opt/stack/devstack# nova  boot  --flavor 1 --image  
cirros-0.3.4-x86_64-uec  --availability-zone nova --nic 
net-id=2de63c95-f645-492c-9197-

5d4d5244a8ba,v4-fixed-ip=1.0.0.087  inst2
ERROR (ClientException): Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
 (HTTP 500) (Request-ID: 
req-17cc4e5a-af9f-44b9-9c4a-b87706682bf3)
root@45-59:/opt/stack/devstack# 

Note: 1.0.0.087 is an ip address in octal format, but it's a wrong
address, octal address can not contain number character bigger than 7.

[Configration]
reproduceable bug, no need

[logs]
reproduceable bug, no need

[Root cause anlyze or debug inf]
reproduceable bug

[Attachment]
None

** Affects: nova
 Importance: Undecided
 Assignee: hgan...@cn.ibm.com (hgangwx)
 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/1526630

Title:
  Unexpected API Error returned when boot an instance with an wrong
  octal ip address as v4-fixed-ip

Status in OpenStack Compute (nova):
  New

Bug description:
  [Summary]
  Unexpected API Error returned when boot an instance with an wrong octal ip 
address as v4-fixed-ip

  [Topo]
  devstack all-in-one node

  [Description and expect result]
  no Unexpected API Error, should return an error says that "Invalid input for 
field/attribute fixed_ip"

  [Reproduceable or not]
  reproduceable 

  [Recreate Steps]
  1) create a network/subnet:
  root@45-59:/opt/stack/devstack# neutron net-list | grep net2
  | 2de63c95-f645-492c-9197-5d4d5244a8ba | net2| 
47eb5e03-c16a-4303-923c-21a061f2909e 1.0.0.0/24  |
  root@45-59:/opt/stack/devstack# 

  
  2) launch an instance with an wrong octal ip address as v4-fixed-ip, 
Unexpected API Error returned:   ISSUE
  root@45-59:/opt/stack/devstack# nova  boot  --flavor 1 --image  
cirros-0.3.4-x86_64-uec  --availability-zone nova --nic 
net-id=2de63c95-f645-492c-9197-

  5d4d5244a8ba,v4-fixed-ip=1.0.0.087  inst2
  ERROR (ClientException): Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
   (HTTP 500) (Request-ID: 
req-17cc4e5a-af9f-44b9-9c4a-b87706682bf3)
  root@45-59:/opt/stack/devstack# 

  Note: 1.0.0.087 is an ip address in octal format, but it's a wrong
  address, octal address can not contain number character bigger than 7.

  [Configration]
  reproduceable bug, no need

  [logs]
  reproduceable bug, no need

  [Root cause anlyze or debug inf]
  reproduceable bug

  [Attachment]
  None

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1526630/+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 1525002] Re: The ironic driver needs to scale back how many errors it traces out

2015-12-15 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/256375
Committed: 
https://git.openstack.org/cgit/openstack/python-ironicclient/commit/?id=8224859c02f525fa3b7dbe917d56b889b0dbb073
Submitter: Jenkins
Branch:master

commit 8224859c02f525fa3b7dbe917d56b889b0dbb073
Author: Dmitry Tantsur 
Date:   Fri Dec 11 12:38:39 2015 +0100

Scale back on how many warnings we issue

* Remove "Request returned failure status" warning, it does not carry
  any helpful information for an operator (or anyone).
* Demote retry warnings to debug level. Retrying is essentially a normal
  thing in the real world, and currently we're spamming logs with warnings.
  
http://logs.openstack.org/93/255793/3/gate/gate-tempest-dsvm-ironic-agent_ssh/25175ed/logs/screen-n-cpu.txt.gz?level=TRACE

Change-Id: I6c40581b9dc5ab1fe3af4b882ede17a13edacc66
Closes-Bug: #1525002


** Changed in: python-ironicclient
   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/1525002

Title:
  The ironic driver needs to scale back how many errors it traces out

Status in Ironic:
  In Progress
Status in OpenStack Compute (nova):
  Confirmed
Status in python-ironicclient:
  Fix Released

Bug description:
  The amount of tracing in this n-cpu log is a bit much:

  http://logs.openstack.org/93/255793/3/gate/gate-tempest-dsvm-ironic-
  agent_ssh/25175ed/logs/screen-n-cpu.txt.gz?level=TRACE

  Like these warnings:

  http://logs.openstack.org/93/255793/3/gate/gate-tempest-dsvm-ironic-
  
agent_ssh/25175ed/logs/screen-n-cpu.txt.gz?level=TRACE#_2015-12-10_16_11_48_799

  2015-12-10 16:11:48.798 WARNING ironicclient.common.http 
[req-94077ab9-5adf-4720-9fb8-2e027dde9b72 tempest-BaremetalBasicOps-1285004585 
tempest-BaremetalBasicOps-1966762451] Request returned failure status.
  2015-12-10 16:11:48.799 WARNING ironicclient.common.http 
[req-94077ab9-5adf-4720-9fb8-2e027dde9b72 tempest-BaremetalBasicOps-1285004585 
tempest-BaremetalBasicOps-1966762451] Error contacting Ironic server: Node 1 is 
locked by host localhost, please retry after the current operation is completed.
  Traceback (most recent call last):

    File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", 
line 150, in inner
  return func(*args, **kwargs)

    File "/opt/stack/new/ironic/ironic/conductor/manager.py", line 1519, in 
update_port
  purpose='port update') as task:

    File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 152, in 
acquire
  driver_name=driver_name, purpose=purpose)

    File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 222, in 
__init__
  self.release_resources()

    File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
204, in __exit__
  six.reraise(self.type_, self.value, self.tb)

    File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 203, in 
__init__
  self._lock()

    File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 243, in 
_lock
  reserve_node()

    File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 49, in 
wrapped_f
  return Retrying(*dargs, **dkw).call(f, *args, **kw)

    File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 212, in call
  raise attempt.get()

    File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 247, in get
  six.reraise(self.value[0], self.value[1], self.value[2])

    File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 200, in call
  attempt = Attempt(fn(*args, **kwargs), attempt_number, False)

    File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 236, in 
reserve_node
  self.node_id)

    File "/opt/stack/new/ironic/ironic/objects/node.py", line 260, in reserve
  db_node = cls.dbapi.reserve_node(tag, node_id)

    File "/opt/stack/new/ironic/ironic/db/sqlalchemy/api.py", line 226, in 
reserve_node
  host=node['reservation'])

  NodeLocked: Node 1 is locked by host localhost, please retry after the 
current operation is completed.
   (HTTP 409). Attempt 1 of 61

  UPD from dtantsur:
  The traceback has nothing to do with ironic client or driver. It gets added 
somewhere between ironic conductor and API levels.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ironic/+bug/1525002/+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 1525740] Re: network availability zone code causes lookups for every network

2015-12-15 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/257086
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=57964df5c6e4d590516ae7eb1783f694fa24f501
Submitter: Jenkins
Branch:master

commit 57964df5c6e4d590516ae7eb1783f694fa24f501
Author: Kevin Benton 
Date:   Sun Dec 13 17:56:57 2015 -0800

Use a joined relationship for AZ info on networks

The previous code was doing a DB lookup for each network's
availability zone which was significantly impacting the
performance of network listings.

This patch adjusts the network model to be automatically joined
to the DHCP agents table that the AZ code uses to populate the
AZs for the network.

Change-Id: I908ceb1a68e0eed7c304e3ff82279ad6fa406167
Closes-Bug: #1525740


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

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

Title:
  network availability zone code causes lookups for every network

Status in neutron:
  Fix Released

Bug description:
  the code to populate network info with availability zone info is
  causing a database lookup in every network dictionary extend function.
  This causes a major regression in network listing performance by doing
  1 DB call per database.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1525740/+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 1526637] [NEW] test for git review,ignore it

2015-12-15 Thread liuhui
Public bug reported:

test for git review,ignore it

** Affects: keystone
 Importance: Undecided
 Assignee: liuhui (leoson)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) => liuhui (leoson)

-- 
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/1526637

Title:
  test for git review,ignore it

Status in OpenStack Identity (keystone):
  New

Bug description:
  test for git review,ignore it

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1526637/+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 1526641] [NEW] Invalid metadata value to location-add causing 500 Internal Server Error

2015-12-15 Thread Abhishek Kekane
Public bug reported:

Passing invalid metadata value to location-add or location-update
command raises 500 Internal Server Error.

1.  glance location-add  --url 
http://10.69.4.136:8111/run_tests.sh --metadata '{"a":1234}'
or
2.  glance location-update  --url 
http://10.69.4.136:8111/run_tests.sh --metadata '{"a":1234}'

Stacktrace on g-api:
 
2015-12-15 03:47:49.876 ERROR glance.common.wsgi 
[req-3a349a22-8b69-40bf-93f1-6388eb5cb4ee 6c9c7376e75b4e37ab3c052a911731dd 
d1ee7fd5dcc341c3973f19f790238e63] Caught error: The image metadata key a has an 
invalid type of . Only dict, list, and unicode are supported.
2015-12-15 03:47:49.876 TRACE glance.common.wsgi Traceback (most recent call 
last):2015-12-15 03:47:49.876 TRACE glance.common.wsgi   File 
"/opt/stack/glance/glance/common/wsgi.py", line 882, in __call__
2015-12-15 03:47:49.876 TRACE glance.common.wsgi request, **action_args)
2015-12-15 03:47:49.876 TRACE glance.common.wsgi   File 
"/opt/stack/glance/glance/common/wsgi.py", line 911, in dispatch
2015-12-15 03:47:49.876 TRACE glance.common.wsgi return method(*args, 
**kwargs)
2015-12-15 03:47:49.876 TRACE glance.common.wsgi   File 
"/opt/stack/glance/glance/common/utils.py", line 423, in wrapped
2015-12-15 03:47:49.876 TRACE glance.common.wsgi return func(self, req, 
*args,**kwargs)
2015-12-15 03:47:49.876 TRACE glance.common.wsgi   File 
"/opt/stack/glance/glance/api/v2/images.py", line 147, in update
2015-12-15 03:47:49.876 TRACE glance.common.wsgi change_method(req, image, 
change)
2015-12-15 03:47:49.876 TRACE glance.common.wsgi   File 
"/opt/stack/glance/glance/api/v2/images.py", line 197, in _do_add
2015-12-15 03:47:49.876 TRACE glance.common.wsgi 
self._do_add_locations(image, path[1], value)
2015-12-15 03:47:49.876 TRACE glance.common.wsgi   File 
"/opt/stack/glance/glance/api/v2/images.py", line 292, in _do_add_locations
2015-12-15 03:47:49.876 TRACE glance.common.wsgi 
image.locations.insert(pos, value)
2015-12-15 03:47:49.876 TRACE glance.common.wsgi   File 
"/opt/stack/glance/glance/api/policy.py", line 275, in _checker
2015-12-15 03:47:49.876 TRACE glance.common.wsgi return method(*args, 
**kwargs)
2015-12-15 03:47:49.876 TRACE glance.common.wsgi   File 
"/opt/stack/glance/glance/quota/__init__.py", line 273, in insert
2015-12-15 03:47:49.876 TRACE glance.common.wsgi return 
self.locations.insert(index, object)
2015-12-15 03:47:49.876 TRACE glance.common.wsgi   File 
"/opt/stack/glance/glance/location.py", line 179, in insert
2015-12-15 03:47:49.876 TRACE glance.common.wsgi location)
2015-12-15 03:47:49.876 TRACE glance.common.wsgi   File 
"/opt/stack/glance/glance/location.py", line 91, in _check_image_location
2015-12-15 03:47:49.876 TRACE glance.common.wsgi 
store_api.check_location_metadata(location['metadata'])
2015-12-15 03:47:49.876 TRACE glance.common.wsgi   File 
"/usr/local/lib/python2.7/dist-packages/glance_store/backend.py", line 309, in 
check_location_metadata
2015-12-15 03:47:49.876 TRACE glance.common.wsgi 
check_location_metadata(val[key], key=key)
2015-12-15 03:47:49.876 TRACE glance.common.wsgi   File 
"/usr/local/lib/python2.7/dist-packages/glance_store/backend.py", line 320, in 
check_location_metadata
2015-12-15 03:47:49.876 TRACE glance.common.wsgi % dict(key=key, 
type=type(val)))
2015-12-15 03:47:49.876 TRACE glance.common.wsgi BackendException: The image 
metadata key a has an invalid type of . Only dict, list, and 
unicode are supported.
2015-12-15 03:47:49.876 TRACE glance.common.wsgi

** Affects: glance
 Importance: Undecided
 Assignee: Abhishek Kekane (abhishek-kekane)
 Status: New

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

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

Title:
  Invalid metadata value to location-add causing 500 Internal Server
  Error

Status in Glance:
  New

Bug description:
  Passing invalid metadata value to location-add or location-update
  command raises 500 Internal Server Error.

  1.glance location-add  --url 
http://10.69.4.136:8111/run_tests.sh --metadata '{"a":1234}'
  or
  2.glance location-update  --url 
http://10.69.4.136:8111/run_tests.sh --metadata '{"a":1234}'

  Stacktrace on g-api:
   
  2015-12-15 03:47:49.876 ERROR glance.common.wsgi 
[req-3a349a22-8b69-40bf-93f1-6388eb5cb4ee 6c9c7376e75b4e37ab3c052a911731dd 
d1ee7fd5dcc341c3973f19f790238e63] Caught error: The image metadata key a has an 
invalid type of . Only dict, list, and unicode are supported.
  2015-12-15 03:47:49.876 TRACE glance.common.wsgi Traceback (most recent call 
last):2015-12-15 03:47:49.876 TRACE glance.common.wsgi   File 
"/opt/stack/glance/glance/common/wsgi.py", line 882, in __call__
  2015-12-15 03:47:49.876 TRACE glance.common.wsgi request, **action_args)
  2015-12-15 03:47:49.876 TRACE glance.common.wsgi 

[Yahoo-eng-team] [Bug 1526644] [NEW] availability zones code issuing query for every router

2015-12-15 Thread Kevin Benton
Public bug reported:

the router availability zone code suffers from the same problem
described in https://bugs.launchpad.net/neutron/+bug/1525740 but for
router listing instead of network listing.

This degrades the response time of router list operations.

** Affects: neutron
 Importance: High
 Assignee: Kevin Benton (kevinbenton)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Kevin Benton (kevinbenton)

** Description changed:

  the router availability zone code suffers from the same problem
  described in https://bugs.launchpad.net/neutron/+bug/1525740 but for
  router listing instead of network listing.
+ 
+ This degrades the response time of router list operations.

** Changed in: neutron
   Importance: Undecided => High

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

Title:
  availability zones code issuing query for every router

Status in neutron:
  New

Bug description:
  the router availability zone code suffers from the same problem
  described in https://bugs.launchpad.net/neutron/+bug/1525740 but for
  router listing instead of network listing.

  This degrades the response time of router list operations.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1526644/+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 1526642] [NEW] Simultaneous live migrations break anti-affinity policy

2015-12-15 Thread Pawel Koniszewski
Public bug reported:

Let's say we have a setup with 3 compute nodes (CN1, CN2 and CN3) and 3
controllers (in HA mode). There are 2 VMs with anti-affinity policy (the
same server group) running in the environment:

* CN1 - VM A (anti-affinity)
* CN2 - VM B (anti-affinity)
* CN3 - empty

If we trigger live migration of VM A and then trigger live migration of
VM B without waiting for scheduling phase of VM A to complete we will
end up with anti-affinity policy violated:

* CN1 - empty
* CN2 - empty
* CN3 - VM A, VM B (both with anti-affinity policy)

Workaround is to wait few seconds and let scheduler finish the job for
the first VM.

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: anti-affinity live-migration scheduler

-- 
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/1526642

Title:
  Simultaneous live migrations break anti-affinity policy

Status in OpenStack Compute (nova):
  New

Bug description:
  Let's say we have a setup with 3 compute nodes (CN1, CN2 and CN3) and
  3 controllers (in HA mode). There are 2 VMs with anti-affinity policy
  (the same server group) running in the environment:

  * CN1 - VM A (anti-affinity)
  * CN2 - VM B (anti-affinity)
  * CN3 - empty

  If we trigger live migration of VM A and then trigger live migration
  of VM B without waiting for scheduling phase of VM A to complete we
  will end up with anti-affinity policy violated:

  * CN1 - empty
  * CN2 - empty
  * CN3 - VM A, VM B (both with anti-affinity policy)

  Workaround is to wait few seconds and let scheduler finish the job for
  the first VM.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1526642/+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