date:20160801

** No longer affects: keystone

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

Title:
  String interpolation should be delayed at logging calls

Status in Ceilometer:
  New
Status in Glance:
  In Progress
Status in glance_store:
  New
Status in heat:
  New
Status in Ironic:
  Fix Released
Status in networking-vsphere:
  Fix Released
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  In Progress
Status in os-brick:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-neutronclient:
  Fix Released
Status in OpenStack Object Storage (swift):
  New
Status in taskflow:
  New

Bug description:
  String interpolation should be delayed to be handled by the logging
  code, rather than being done at the point of the logging call.

  Wrong: LOG.debug('Example: %s' % 'bad')
  Right: LOG.debug('Example: %s', 'good')

  See the following guideline.

  * http://docs.openstack.org/developer/oslo.i18n/guidelines.html
  #adding-variables-to-log-messages

  The rule for it should be added to hacking checks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1596829/+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 1592711] Re: Missing doc for "list of roles assigned to a user for a tenant" on identity v2 API

Looks documented to me: http://developer.openstack.org/api-
ref/identity/v2-admin/index.html?expanded=list-roles-for-user-detail
#list-roles-for-user

** Changed in: keystone
   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/1592711

Title:
  Missing doc for "list of roles assigned to a user for a tenant" on
  identity v2 API

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  Keystone has API for "list of roles assigned to a user for a tenant" -
  '/tenants/%s/users/%s/roles' % (tenant_id, user_id)

  However, the api-site doesn't contain the API description.
  So we need to write the API for API users.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1592711/+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 1555629] Re: v3/users reports all users in all domains excepts when domain_specific_drivers_enabled is set to true.

Sounds like this is a WONTFIX.

** Changed in: keystone
   Status: New => Won't Fix

** Changed in: keystone
 Assignee: Henry Nash (henry-nash) => (unassigned)

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

Title:
  v3/users reports all users in all domains excepts when
  domain_specific_drivers_enabled is set to true.

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  Hi,

  Setting "domain_specific_drivers_enabled=true" in the keystone.conf,
  prevents my calls to "/v3/users" to works when using the admin_token:

  @token="admin_token", @url="http://127.0.0.1:35357/v3

  ->

  /bin/openstack user list --quiet --format csv --long'
  127.0.0.1 - - [10/Mar/2016:08:15:41 -0500] "GET /v3/users HTTP/1.1" 401 
114 "-" "python-keystoneclient"

  If I add a domain option to the openstack user list command, I get the
  users of the domain (not 401)

  If I do a project list it works and returns the complete list of all
  projects in all domains:

  Debug: Executing '/bin/openstack project list --quiet --format csv --long'
  127.0.0.1 - - [10/Mar/2016:08:22:00 -0500] "GET /v3/projects HTTP/1.1" 
200 471 "-" "python-keystoneclient"
  => [{:id=>"1ff87dbb8e6e45d5b43a49a812fafb88", :name=>"admin", 
:domain_id=>"default", :description=>"Bootstrap project for initializing the 
cloud.", :enabled=>"True"},
   {:id=>"60f86c662af248449c1007fbf32ed5af", :name=>"openstackv3", 
:domain_id=>"463e1bb751374a0586a867a73cb35330", :description=>"admin tenant", 
:enabled=>"True"},
   {:id=>"746e5e3d02b04d079dfa639ac5d03886", :name=>"services", 
:domain_id=>"default", :description=>"Tenant for the openstack services", 
:enabled=>"True"},
   {:id=>"bcf81b0d73b74c85b01e1b15f38be64e", :name=>"openstack", 
:domain_id=>"default", :description=>"admin tenant", :enabled=>"True"},
   {:id=>"e00959d5ac2545a5a77d137d20e0f9f8", :name=>"servicesv3", 
:domain_id=>"a43714e50901474eb328daf380ef24ee", :description=>"Tenant for the 
openstack services", :enabled=>"True"}]

  If I try the exact same command (without the domain option) with
  "domain_specific_drivers_enabled=false" in keystone.conf, I get the
  list of users in all domains.

  This is rather confusing.  The "401", unauthorized error is confusing.
  The discrepancy between user and project behavior is confusing.

  So what is the "correct" behavior ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1555629/+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 1585632] Re: test_revoke_by_audit_chain_id_chained_token() fails

** Changed in: keystone
   Status: Incomplete => 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/1585632

Title:
  test_revoke_by_audit_chain_id_chained_token() fails

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  This test started failing in Ubuntu package builds as of commit
  79952ffbd4c1ffd2dab32c04581b3a7f71a05e28.

  ==
  Failed 1 tests - output below:
  ==

  
keystone.tests.unit.test_auth.FernetAuthWithToken.test_revoke_by_audit_chain_id_chained_token
  
-

  Captured traceback:
  ~~~
  Traceback (most recent call last):
File "/��PKGBUILDDIR��/keystone/tests/unit/test_auth.py", line 595, in 
test_revoke_by_audit_chain_id_chained_token
  token_id=token_id)
File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 
422, in assertRaises
  self.assertThat(our_callable, matcher)
File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 
435, in assertThat
  raise mismatch_error
  testtools.matchers._impl.MismatchError: > returned {'access': {'token': {'issued_at': 
'2016-05-25T04:29:17.00Z', 'expires': '2016-05-25T05:29:14.00Z', 'id': 
u'gABXRSodRmWvyRUcgKFIelwt9imwkJYBsdVmL3DSNEN7rntAzfi0bpFSB4fWfSsZ61G7ETkEjDoFGOfV_lycQpUhTSZg1JFKK4Tc_cCk04aDq6vLVMnW7ZEjSZ4KTNsyKrbKtZVNbVi254Rg3vNizFUysVsG-w',
 'audit_ids': [u'DIO9TonYRu6riZal9j7keg']}, 'serviceCatalog': [], 'user': 
{'username': u'FOO', 'roles_links': [], 'id': 
u'cad5986016664bb3927a3a6195581a0c', 'roles': [], 'name': u'FOO'}, 'metadata': 
{'is_admin': 0, 'roles': []}}}

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1585632/+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 1588654] Re: External auth method has problem in getting the head of REMOTE_USER

This has expired

** Changed in: keystone
   Status: Incomplete => 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/1588654

Title:
  External auth method has problem in getting the head of REMOTE_USER

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  When enable the external method, It need to pass a REMOTE_USER as a log user.
  For now it can't get the head of REMOTE_USER, and we should modify the method 
in controller.py.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1588654/+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 1547997] Re: Liberty:During horizon dashbord installation found all keystone database entry gets deleted.

Expired

** Changed in: keystone
   Status: Incomplete => 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/1547997

Title:
  Liberty:During horizon dashbord installation found all keystone
  database entry gets deleted.

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  During liberty installation found that openstack-dashboard deletes all
  keystone database details like user,project,endpoints etc...

  steps followed:
  
http://fosskb.in/2015/10/20/openstack-liberty-on-ubuntu-14-04-and-ubuntu-15-10/

  liberty version:
  root@ubuntu-osc:~# dpkg -l | grep neutron
  ii  neutron-common  2:7.0.1-0ubuntu1~cloud0   
all  Neutron is a virtual network service for Openstack - common
  ii  neutron-dhcp-agent  2:7.0.1-0ubuntu1~cloud0   
all  Neutron is a virtual network service for Openstack - DHCP agent
  ii  neutron-l3-agent2:7.0.1-0ubuntu1~cloud0   
all  Neutron is a virtual network service for Openstack - l3 agent
  ii  neutron-metadata-agent  2:7.0.1-0ubuntu1~cloud0   
all  Neutron is a virtual network service for Openstack - metadata agent
  ii  neutron-plugin-ml2  2:7.0.1-0ubuntu1~cloud0   
all  Neutron is a virtual network service for Openstack - ML2 plugin
  ii  neutron-plugin-openvswitch  1:2015.1~rc1-0ubuntu1~cloud0  
all  Neutron is a virtual network service for Openstack - Open vSwitch 
plugin
  ii  neutron-plugin-openvswitch-agent2:7.0.1-0ubuntu1~cloud0   
all  Neutron is a virtual network service for Openstack - Open vSwitch 
plugin agent
  ii  neutron-server  2:7.0.1-0ubuntu1~cloud0   
all  Neutron is a virtual network service for Openstack - server
  ii  python-neutron  2:7.0.1-0ubuntu1~cloud0   
all  Neutron is a virtual network service for Openstack - Python library
  ii  python-neutron-fwaas1:7.0.0-0ubuntu1~cloud0   
all  Firewall-as-a-Service driver for OpenStack Neutron
  ii  python-neutronclient1:3.1.0-0ubuntu1~cloud0   
all  client API library for Neutron
  root@ubuntu-osc:~#

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1547997/+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 1582533] Re: Keystone installation fails

Expired

** Changed in: keystone
 Assignee: Upama (upamajohri-os) => (unassigned)

** Changed in: keystone
   Status: Incomplete => 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/1582533

Title:
  Keystone installation fails

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  Keystone installation fails due to duplicate requirement in
  requirements.txt which was introduced by change ID
  I11f428bdc8395079ca65654eabbba33a1c8f305d

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1582533/+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 1590426] Re: Keystone Federated Identity assertion name not included in token

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

** This bug has been marked a duplicate of bug 1482701
   Federation: user's name in rules not respected

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

Title:
  Keystone Federated Identity assertion name not included in token

Status in OpenStack Identity (keystone):
  Incomplete

Bug description:
  When using keystone Federated Identity, the user name, based on the
  assertion mapping, is replaced in Keystone tokens by the autogenerated
  ID, resulting in e.g. Horizon showing the user's ID instead of the
  name (see attachment).

  Running "openstack user list" shows the correct data:

  +--+--+
  | ID   | Name |
  +--+--+
  | 1835f12340674587b8e9b55ac1b43a3c | te...@acme.com   |
  +--+--+

  The issue is clearly visible in the logs:

  016-05-26 10:08:02.809220
  DEBUG:keystoneauth.identity.v3.base:{"token": {"issued_at":
  "2016-05-26T10:08:02.804697Z", "user": {"OS-FEDERATION":
  {"identity_provider": {"id": "idp_1"}, "protocol": {"id": "saml2"},
  "groups": [{"id": "b07974d2891f4d939b91a288ea933b1e"}]}, "domain":
  {"id": "Federated", "name": "Federated"}, "id":
  "1835f12340674587b8e9b55ac1b43a3c", "name":
  "1835f12340674587b8e9b55ac1b43a3c"}, "methods": ["token"],
  "expires_at": "2016-05-26T11:08:02.804676Z", "audit_ids":
  ["4O86fwqsSd6LSge4123sdx"]}}

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

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

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

** No longer affects: python-keystoneclient

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

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

Status in Cinder:
  Invalid
Status in Magnum:
  Fix Released
Status in OpenStack Compute (nova):
  Confirmed
Status in python-glanceclient:
  New
Status in python-neutronclient:
  In Progress
Status in python-troveclient:
  New
Status in OpenStack DBaaS (Trove):
  New

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

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

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

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

[Yahoo-eng-team] [Bug 1586268] Re: Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq does not work in PY2

** No longer affects: python-keystoneclient

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

Title:
  Unit test: self.assertNotEqual in  unit.test_base.BaseTest.test_eq
  does not work in PY2

Status in Ceilometer:
  Fix Released
Status in daisycloud-core:
  New
Status in heat:
  New
Status in OpenStack Dashboard (Horizon):
  New
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in python-barbicanclient:
  New
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-glanceclient:
  In Progress
Status in python-heatclient:
  Fix Released
Status in python-manilaclient:
  New
Status in python-muranoclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in python-smaugclient:
  Fix Released
Status in python-troveclient:
  In Progress
Status in tempest:
  In Progress

Bug description:
  Version: master(20160527)

  In case cinderclient.tests.unit.test_base.BaseTest.test_eq 
self.assertNotEqual does not work.
  Class base.Resource defines __eq__() built-in function, but does not define 
__ne__() built-in function, so self.assertEqual works but self.assertNotEqual 
does not work at all in this test case.

  steps:
  1 Clone code of python-cinderclient from master.
  2 Modify the case of unit test: cinderclient/tests/unit/test_base.py
    line50--line62.
  def test_eq(self):
  # Two resources with same ID: never equal if their info is not equal
  r1 = base.Resource(None, {'id': 1, 'name': 'hi'})
  r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
  self.assertNotEqual(r1, r2)

  # Two resources with same ID: equal if their info is equal
  r1 = base.Resource(None, {'id': 1, 'name': 'hello'})
  r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
  # self.assertEqual(r1, r2)
  self.assertNotEqual(r1, r2)

  # Two resoruces of different types: never equal
  r1 = base.Resource(None, {'id': 1})
  r2 = volumes.Volume(None, {'id': 1})
  self.assertNotEqual(r1, r2)

  # Two resources with no ID: equal if their info is equal
  r1 = base.Resource(None, {'name': 'joe', 'age': 12})
  r2 = base.Resource(None, {'name': 'joe', 'age': 12})
  # self.assertEqual(r1, r2)
  self.assertNotEqual(r1, r2)

     Modify self.assertEqual(r1, r2) to self.assertNotEqual(r1, r2).

  3 Run unit test, and return success.

  After that, I make a test:

  class Resource(object):
  def __init__(self, person):
  self.person = person

  def __eq__(self, other):
  return self.person == other.person

  r1 = Resource("test")
  r2 = Resource("test")
  r3 = Resource("test_r3")
  r4 = Resource("test_r4")

  print r1 != r2
  print r1 == r2
  print r3 != r4
  print r3 == r4

  The result is :
  True
  True
  True
  False

  Whether r1 is precisely the same to r2 or not, self.assertNotEqual(r1,
  r2) return true.So I think self.assertNotEqual doesn't work at all in
  python2 and  should be modified.

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

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

[Yahoo-eng-team] [Bug 1608653] Re: Add libpg-dev to developer docs

Reviewed:  https://review.openstack.org/349688
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=44ccc92c1ac368f5318d162957c58ea35ba74150
Submitter: Jenkins
Branch:master

commit 44ccc92c1ac368f5318d162957c58ea35ba74150
Author: Gage Hugo 
Date:   Mon Aug 1 15:20:04 2016 -0500

Added postgresql libs to developer docs

Added corresponding packages for postgresql libraries for various
distros to the development docs to avoid causing pip to fail when
installing dependencies within test-requirements.txt

Change-Id: Ie181cf01bb22366b80d0639e66d939aaa948490b
Closes-Bug: #1608653


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

Title:
  Add libpg-dev to developer docs

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  When setting up a development environment following the instructions
  here:

  
http://docs.openstack.org/developer/keystone/devref/development.environment.html

  On Ubuntu 16.04.1 when installing dependencies from test-
  requirements.txt using pip, the installation fails when it tries to
  install psycopg2:

  Collecting psycopg2>=2.5; extra == "postgresql" (from 
oslo.db[fixtures,mysql,postgresql]>=4.1.0->-r test-requirements.txt (line 13))
Downloading psycopg2-2.6.2.tar.gz (376kB)
  100% || 378kB 769kB/s
  Complete output from command python setup.py egg_info:
  running egg_info
  creating pip-egg-info/psycopg2.egg-info
  writing pip-egg-info/psycopg2.egg-info/PKG-INFO
  writing top-level names to pip-egg-info/psycopg2.egg-info/top_level.txt
  writing dependency_links to 
pip-egg-info/psycopg2.egg-info/dependency_links.txt
  writing manifest file 'pip-egg-info/psycopg2.egg-info/SOURCES.txt'
  warning: manifest_maker: standard file '-c' not found

  Error: pg_config executable not found.

  Please add the directory containing pg_config to the PATH
  or specify the full executable path with the option:

  python setup.py build_ext --pg-config /path/to/pg_config build
  ...

  or with the pg_config option in 'setup.cfg'.

  
  Command "python setup.py egg_info" failed with error code 1 in 
/tmp/pip-build-j460mO/psycopg2/

  
  Googling this error brings you to this fix from stackoverflow:

  http://stackoverflow.com/questions/11618898/pg-config-executable-not-
  found

  Which simply involves installing the libpq-dev package.  This fixes
  the problem and the rest of test-requirements.txt are installed fine.

  Recommend adding libpg-dev (Ubuntu/Debian) along with other package
  managers to the list of dependencies to install before using pip:

  
http://docs.openstack.org/developer/keystone/devref/development.environment.html
  #installing-dependencies

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

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

[Yahoo-eng-team] [Bug 1586268] Re: Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq does not work in PY2

** No longer affects: keystonemiddleware

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

Title:
  Unit test: self.assertNotEqual in  unit.test_base.BaseTest.test_eq
  does not work in PY2

Status in Ceilometer:
  Fix Released
Status in daisycloud-core:
  New
Status in heat:
  New
Status in OpenStack Dashboard (Horizon):
  New
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in python-barbicanclient:
  New
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-glanceclient:
  In Progress
Status in python-heatclient:
  Fix Released
Status in python-manilaclient:
  New
Status in python-muranoclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in python-smaugclient:
  Fix Released
Status in python-troveclient:
  In Progress
Status in tempest:
  In Progress

Bug description:
  Version: master(20160527)

  In case cinderclient.tests.unit.test_base.BaseTest.test_eq 
self.assertNotEqual does not work.
  Class base.Resource defines __eq__() built-in function, but does not define 
__ne__() built-in function, so self.assertEqual works but self.assertNotEqual 
does not work at all in this test case.

  steps:
  1 Clone code of python-cinderclient from master.
  2 Modify the case of unit test: cinderclient/tests/unit/test_base.py
    line50--line62.
  def test_eq(self):
  # Two resources with same ID: never equal if their info is not equal
  r1 = base.Resource(None, {'id': 1, 'name': 'hi'})
  r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
  self.assertNotEqual(r1, r2)

  # Two resources with same ID: equal if their info is equal
  r1 = base.Resource(None, {'id': 1, 'name': 'hello'})
  r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
  # self.assertEqual(r1, r2)
  self.assertNotEqual(r1, r2)

  # Two resoruces of different types: never equal
  r1 = base.Resource(None, {'id': 1})
  r2 = volumes.Volume(None, {'id': 1})
  self.assertNotEqual(r1, r2)

  # Two resources with no ID: equal if their info is equal
  r1 = base.Resource(None, {'name': 'joe', 'age': 12})
  r2 = base.Resource(None, {'name': 'joe', 'age': 12})
  # self.assertEqual(r1, r2)
  self.assertNotEqual(r1, r2)

     Modify self.assertEqual(r1, r2) to self.assertNotEqual(r1, r2).

  3 Run unit test, and return success.

  After that, I make a test:

  class Resource(object):
  def __init__(self, person):
  self.person = person

  def __eq__(self, other):
  return self.person == other.person

  r1 = Resource("test")
  r2 = Resource("test")
  r3 = Resource("test_r3")
  r4 = Resource("test_r4")

  print r1 != r2
  print r1 == r2
  print r3 != r4
  print r3 == r4

  The result is :
  True
  True
  True
  False

  Whether r1 is precisely the same to r2 or not, self.assertNotEqual(r1,
  r2) return true.So I think self.assertNotEqual doesn't work at all in
  python2 and  should be modified.

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

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

[Yahoo-eng-team] [Bug 1588691] Re: 'keystone_authtoken.user_domain_id' is not in config

** Changed in: keystonemiddleware
   Status: Incomplete => 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/1588691

Title:
  'keystone_authtoken.user_domain_id' is not in config

Status in OpenStack Identity (keystone):
  Invalid
Status in keystonemiddleware:
  Invalid

Bug description:
  During migrating to keystone v3 murano-team faced a problem with getting 
domain variables such as project_domain_name, project_domain_id, 
user_domain_name and user_domain_id. Looks like it never have been placed in 
the right place.
  According the description it should be in config:
  
https://github.com/openstack/keystonemiddleware/blob/f55b0334b919f89fee0b2cfe0a9994fd08c9966c/keystonemiddleware/auth_token/__init__.py#L189

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1588691/+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 1498556] Re: Reasonable assumptions concerning domain references

Setting middleware and client to invalid, very unlikely they will be
affected

** Changed in: keystonemiddleware
   Status: Triaged => Invalid

** Changed in: python-keystoneclient
   Status: Triaged => 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/1498556

Title:
  Reasonable assumptions concerning domain references

Status in OpenStack Identity (keystone):
  Triaged
Status in keystoneauth:
  Triaged
Status in keystonemiddleware:
  Invalid
Status in python-keystoneclient:
  Invalid
Status in python-openstackclient:
  Triaged
Status in OpenStack SDK:
  New

Bug description:
  There are 3 primary places where client can be configured to reference
  domains. The actual parameter names vary based on the configuration
  interface (a function's arguments, the env, CLI arguments, etc), but
  I'll use environment variables here for the sake of general
  familiarity:

  1. OS_USER_DOMAIN_ID and OS_USER_DOMAIN_NAME: Used for specifying the
  domain which owns the authenticating user.

  2. OS_PROJECT_DOMAIN_ID and OS_PROJECT_DOMAIN_NAME: Used for
  specifying the domain which owns the desired project scope.

  3. OS_DOMAIN_ID and OS_DOMAIN_NAME: Used for specifying the desired
  domain scope.

  On the service side, a "default domain" is created which, by default,
  looks like:

    id="default"

    name="Default"

  The default domain is exclusively used on the service-side for scoping
  v2 operations, which are not domain-aware, in the broader multi-domain
  namespace exposed by v3. The default domain's ID is mutable via
  configuration (CONF.identity.default_domain_id) and the domain name is
  mutable via the API (PATCH /v3/domains/default, for example).
  Generally, deployers should not have any reason to change the default
  domain ID from it's default value of "default".

  Both (1) and (2) refer to domains that provide context to other
  configuration options. In single domain deployments, or deployments
  wherein most users and projects exist in the "default domain", it
  would benefit the user experience to assume that the user's and
  project exist in the default domain. Specifically, this means that
  users have fewer (if any) additional configuration options to set when
  migrating from v2 to v3, easing adoption of v3 overall. Deployments
  that opt into more complex multi-domain arrangement are thus opting
  into consuming more complex configuration options on the client side
  (they must specify their non-default domains explicitly).

  On (3), these values should always default to null values, and no
  assumptions should ever be made about their values. If a non-null
  default were to be set, then that means that the client should always
  try to obtain a domain-scoped token which is almost never the intended
  behavior.

  There are three approaches to implementing this behavior. Two of them
  are obvious at a high level, but easily fragile.

  If OS_USER_DOMAIN_ID defaults to "default" to match the default
  CONF.identity.default_domain_id value, then whenever the user sets a
  OS_USER_DOMAIN_NAME, the OS_USER_DOMAIN_ID *must* be ignored in favor
  of using the specified domain name. This is a potentially unreliable
  behavior, as domain IDs are immutable and are thus more preferable as
  reliable references.

  If OS_USER_DOMAIN_NAME defaults to "Default" to match the default
  domain name value, then whenever the user sets a OS_USER_DOMAIN_ID,
  the OS_USER_DOMAIN_NAME *must* be ignored in favor of using the
  specified domain ID. This is a potentially unreliable behavior, as
  assuming that the default domain still has a default domain name of
  "Default" is fragile considering that it's mutable through the regular
  HTTP API (a deployer will inevitably change it, thus breaking the
  client's default behavior). This approach is fragile.

  The third option is a combination of the above two approaches, and
  must happen at the "last minute" before requests are issued to
  keystone (after all possible sources of configuration have been
  handled). That is, both OS_USER_DOMAIN_ID and OS_USER_DOMAIN_NAME
  default to null values on the surface. When an actual HTTP request is
  built, normal configuration precedence takes place (for example, in a
  CLI client):

  1) If an --os-user-domain-id is specified, then that is used, ignoring
  --os-user-domain-name, OS_USER_DOMAIN_ID, and OS_USER_DOMAIN_NAME.
  This is the most specific, reliable configuration option available. A
  warning could be issued about the ignored values being discarded to
  communicate this sequence of precedence.

  2) If an --os-user-domain-name is specified, then that is used,
  ignoring OS_USER_DOMAIN_ID, and OS_USER_DOMAIN_NAME.

  3) If an OS_USER_DOMAIN_ID, then that is used, ignoring
  OS_USER_DOMAIN_NAME.

  4) If an OS_USER_DOMAIN_NAME, then that is used.

  5) Else, assume

[Yahoo-eng-team] [Bug 1592988] Re: openstackclient is not authorized to lookup domains by name

See https://review.openstack.org/#/c/311206/

** Changed in: python-openstackclient
 Assignee: venkatamahesh (venkatamaheshkotha) => (unassigned)

** Changed in: python-openstackclient
   Status: Incomplete => Fix Released

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

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

Title:
  openstackclient is not authorized to lookup domains by name

Status in OpenStack Identity (keystone):
  Won't Fix
Status in python-keystoneclient:
  Invalid
Status in python-openstackclient:
  Fix Released

Bug description:
  Reported by Eduard Barrera in
  https://bugzilla.redhat.com/show_bug.cgi?id=1346886

  Keystone is not properly looking up the domain_id, please check the
  highlighted log lines

  
  # openstack project create --domain my_domain my_domain_project1
   
  2016-06-15 04:52:06.795 9535 DEBUG keystone.middleware.core [-] Auth token 
not in the request header. Will not build auth context. process_request 
/usr/lib/python2.7/site-packages/keystone/middleware/core.py:223
  2016-06-15 04:52:06.798 9535 INFO keystone.common.wsgi [-] POST 
http://192.168.101.196:5000/v3/auth/tokens
   
  2016-06-15 04:52:06.897 9535 DEBUG keystone.middleware.core [-] Auth token 
not in the request header. Will not build auth context. process_request 
/usr/lib/python2.7/site-packages/keystone/middleware/core.py:223
  2016-06-15 04:52:06.899 9535 INFO keystone.common.wsgi [-] POST 
http://192.168.101.196:5000/v3/auth/tokens
  2016-06-15 04:52:06.978 14354 INFO keystone.common.wsgi [-] GET 
http://192.168.101.196:35357/
  2016-06-15 04:52:06.986 14354 DEBUG keystone.middleware.core [-] RBAC: 
auth_context: {'is_delegated_auth': False, 'user_id': 
u'7f603b47d9a14ed2aa4f10d0182c2e3e', 'roles': [u'admin'], 'trustee_id': None, 
'trustor_id': None, 'consumer_id': None, 'token': , 'access_token_id': None, 'domain_id': 
u'2e25369784564c508fdb51903ce98368', 'trust_id': None} process_request 
/usr/lib/python2.7/site-packages/keystone/middleware/core.py:233
  2016-06-15 04:52:06.988 14354 INFO keystone.common.wsgi [-] GET 
http://192.168.101.196:35357/v3/domains/my_domain
  2016-06-15 04:52:06.988 14354 DEBUG keystone.common.controller [-] RBAC: 
Authorizing identity:get_domain(domain_id=my_domain) 
_build_policy_check_credentials 
/usr/lib/python2.7/site-packages/keystone/common/controller.py:61

  <===

  2016-06-15 04:52:06.989 14354 DEBUG keystone.common.controller [-] RBAC: 
using auth context from the request environment _build_policy_check_credentials 
/usr/lib/python2.7/site-packages/keystone/common/controller.py:66
  2016-06-15 04:52:06.992 14354 WARNING keystone.common.wsgi [-] Could not find 
domain: my_domain
  2016-06-15 04:52:07.000 14354 DEBUG keystone.middleware.core [-] RBAC: 
auth_context: {'is_delegated_auth': False, 'user_id': 
u'7f603b47d9a14ed2aa4f10d0182c2e3e', 'roles': [u'admin'], 'trustee_id': None, 
'trustor_id': None, 'consumer_id': None, 'token': , 'access_token_id': None, 'domain_id': 
u'2e25369784564c508fdb51903ce98368', 'trust_id': None} process_request 
/usr/lib/python2.7/site-packages/keystone/middleware/core.py:233
  2016-06-15 04:52:07.002 14354 INFO keystone.common.wsgi [-] GET 
http://192.168.101.196:35357/v3/domains?name=my_domain
  2016-06-15 04:52:07.002 14354 DEBUG keystone.common.controller [-] RBAC: 
Authorizing identity:list_domains() _build_policy_check_credentials 
/usr/lib/python2.7/site-packages/keystone/common/controller.py:61
  2016-06-15 04:52:07.002 14354 DEBUG keystone.common.controller [-] RBAC: 
using auth context from the request environment _build_policy_check_credentials 
/usr/lib/python2.7/site-packages/keystone/common/controller.py:66
  2016-06-15 04:52:07.003 14354 DEBUG keystone.common.controller [-] RBAC: 
Adding query filter params (name=my_domain) wrapper 
/usr/lib/python2.7/site-packages/keystone/common/controller.py:193
  2016-06-15 04:52:07.003 14354 DEBUG keystone.policy.backends.rules [-] 
enforce identity:list_domains: {'is_delegated_auth': False, 'user_id': 
u'7f603b47d9a14ed2aa4f10d0182c2e3e', 'roles': [u'admin'], 'trustee_id': None, 
'trustor_id': None, 'consumer_id': None, 'token': , 'access_token_id': None, 'domain_id': 
u'2e25369784564c508fdb51903ce98368', 'trust_id': None} enforce 
/usr/lib/python2.7/site-packages/keystone/policy/backends/rules.py:76
  2016-06-15 04:52:07.005 14354 WARNING keystone.common.wsgi [-] You are not 
authorized to perform the requested action: identity:list_domains (Disable 
debug mode to suppress these details.)
   
  <===
   
  2016-06-15 04:52:07.017 14354 DEBUG keystone.middleware.core [-] RBAC: 
auth_context: {'is_delegated_auth': False, 'user_id': 
u'7f603b47d9a14ed2aa4f10d0182c2e3e', 'roles': [u'admin'], 'trustee_id': None, 
'trustor_id': None, 'consumer_id': None, 'token': ,

[Yahoo-eng-team] [Bug 1526087] Re: Can edit user name, email to illegal values

Refer to https://review.openstack.org/#/c/345022/ for the keystone fix,
which should fix things in OSC

** Changed in: python-openstackclient
   Status: Confirmed => Invalid

** Changed in: keystone
   Status: Confirmed => 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/1526087

Title:
  Can edit user name, email to illegal values

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in OpenStack Identity (keystone):
  Fix Released
Status in python-openstackclient:
  Invalid

Bug description:
  Under Identity > Users, you can edit usernames and emails to illegal
  values (string too long, invalid characters/format, etc). The test
  string for both email and username update is
  "abcdefghijklmnopqrstuvwxyz!@#$%^&*()_+1234567890-=[]\{}|;':",./<>?
  baduser2".

  This behavior is not in line with user creation's validation. When you
  attempt to create a user with the test string as a username or email,
  you get an error. This validation present during user creation does
  not appear to be active when editing the user's name or email.

  Furthermore, when you set the user's name to the test string, you will
  be unable to log on using that username due to a name length issue.
  The test string's length is 75 characters; the horizon log-on maximum
  is 64.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1526087/+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 1534473] Re: openstack service create allows duplicate names

We can't enforce uniqueness with service names and types, and we can't
break backward compatibility.

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

** Changed in: keystone
 Assignee: Kanika Singh (kanikasingh-1490) => (unassigned)

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

Title:
  openstack service create allows duplicate names

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  $ openstack service create   --name keystone --description "OpenStack 
Identity" identity
  +-+--+
  | Field   | Value|
  +-+--+
  | description | OpenStack Identity   |
  | enabled | True |
  | id  | fbf58f4a39624bcf9c434a99e5e081fa |
  | name| keystone |
  | type| identity |
  +-+--+

  $ openstack service create   --name keystone --description "OpenStack 
Identity" identity
  +-+--+
  | Field   | Value|
  +-+--+
  | description | OpenStack Identity   |
  | enabled | True |
  | id  | 7bd7431cbd2040a7a0d732560cbd4836 |
  | name| keystone |
  | type| identity |
  +-+--+

  $ openstack service list
  +--+--+--+
  | ID   | Name | Type |
  +--+--+--+
  | 7bd7431cbd2040a7a0d732560cbd4836 | keystone | identity |
  | fbf58f4a39624bcf9c434a99e5e081fa | keystone | identity |
  +--+--+--+

  Here we can see, that duplicate service names are created using
  openstack service create command.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1534473/+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 1606659] Re: add-tag Normal response code is 200, not 201

2016-08-01 Thread Hirofumi Ichihara

This is not bug.

** Changed in: neutron
   Status: In Progress => 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/1606659

Title:
  add-tag Normal response code is 200, not 201

Status in neutron:
  Invalid

Bug description:
  This is found at stable/mitaka release

  According to networking API v2.0 extensions:
  
http://developer.openstack.org/api-ref/networking/v2-ext/index.html?expanded=add-a-tag-detail,confirm-a-tag-detail,remove-all-tags-detail,replace-all-tags-detail,remove-a-tag-detail#tag-extension-tags

  API DOC:
  ##
  PUT /v2.0/{resource_type}/{resource_id}/tags/{tag}Add a tagclose
  Adds a tag on the resource.

  Error response codes:201,404,500,401,503,

  Although the document did not specify normal response code is 200. It
  is generally 200 to represent an successful operation.

  The current response code is 201 when tag is added.

  stack@falcon-devstack ~
  $ neutron --debug tag-add --resource-type network --resource 
tempest-test-network--402537940 --tag xBlue
  DEBUG: stevedore.extension found extension EntryPoint.parse('v2token = 
keystoneauth1.loading._plugins.identity.v2:Token')
  DEBUG: stevedore.extension found extension EntryPoint.parse('admin_token = 
keystoneauth1.loading._plugins.admin_token:AdminToken')
  DEBUG: stevedore.extension found extension EntryPoint.parse('v3oidcauthcode = 
keystoneauth1.loading._plugins.identity.v3:OpenIDConnectAuthorizationCode')
  DEBUG: stevedore.extension found extension EntryPoint.parse('v2password = 
keystoneauth1.loading._plugins.identity.v2:Password')
  DEBUG: stevedore.extension found extension EntryPoint.parse('v3password = 
keystoneauth1.loading._plugins.identity.v3:Password')
  DEBUG: stevedore.extension found extension EntryPoint.parse('v3oidcpassword = 
keystoneauth1.loading._plugins.identity.v3:OpenIDConnectPassword')
  DEBUG: stevedore.extension found extension EntryPoint.parse('token = 
keystoneauth1.loading._plugins.identity.generic:Token')
  DEBUG: stevedore.extension found extension EntryPoint.parse('v3token = 
keystoneauth1.loading._plugins.identity.v3:Token')
  DEBUG: stevedore.extension found extension EntryPoint.parse('password = 
keystoneauth1.loading._plugins.identity.generic:Password')
  DEBUG: neutronclient.neutron.v2_0.tag.AddTag 
run(Namespace(request_format='json', 
resource=u'tempest-test-network--402537940', resource_type=u'network', 
tag=u'xBlue'))
  DEBUG: keystoneauth.session REQ: curl -g -i -X GET 
http://10.34.57.68:5000/v2.0 -H "Accept: application/json" -H "User-Agent: 
keystoneauth1/2.4.0 python-requests/2.9.1 CPython/2.7.6"
  DEBUG: keystoneauth.session RESP: [200] Content-Length: 337 Vary: 
X-Auth-Token Keep-Alive: timeout=5, max=100 Server: Apache/2.4.10 (Ubuntu) 
Connection: Keep-Alive Date: Tue, 26 Jul 2016 15:46:42 GMT Content-Type: 
application/json x-openstack-request-id: 
req-6dd80f57-ec78-4bdb-8d2b-a6f15e48211f 
  RESP BODY: {"version": {"status": "stable", "updated": 
"2014-04-17T00:00:00Z", "media-types": [{"base": "application/json", "type": 
"application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", "links": 
[{"href": "http://10.34.57.68:5000/v2.0/;, "rel": "self"}, {"href": 
"http://docs.openstack.org/;, "type": "text/html", "rel": "describedby"}]}}

  DEBUG: keystoneauth.identity.v2 Making authentication request to 
http://10.34.57.68:5000/v2.0/tokens
  DEBUG: stevedore.extension found extension 
EntryPoint.parse('l2_gateway_connection = 
networking_l2gw.l2gatewayclient.l2gw_client_ext._l2_gateway_connection')
  DEBUG: stevedore.extension found extension EntryPoint.parse('l2_gateway = 
networking_l2gw.l2gatewayclient.l2gw_client_ext._l2_gateway')
  DEBUG: keystoneauth.session REQ: curl -g -i -X GET 
http://10.34.57.68:9696/v2.0/networks.json?fields=id=tempest-test-network--402537940
 -H "User-Agent: python-neutronclient" -H "Accept: application/json" -H 
"X-Auth-Token: {SHA1}a02258f9d970cdb9c1c2e483389f103d34134991"
  DEBUG: keystoneauth.session RESP: [200] Date: Tue, 26 Jul 2016 15:46:42 GMT 
Connection: keep-alive Content-Type: application/json; charset=UTF-8 
Content-Length: 62 X-Openstack-Request-Id: 
req-28ce177f-042d-488e-b595-370d263873fe 
  RESP BODY: {"networks": [{"id": "2907e8e9-b825-4f53-bd1f-1a974edbc345"}]}

  DEBUG: keystoneauth.session REQ: curl -g -i -X PUT 
http://10.34.57.68:9696/v2.0/networks/2907e8e9-b825-4f53-bd1f-1a974edbc345/tags/xBlue.json
 -H "User-Agent: python-neutronclient" -H "Accept: application/json" -H 
"X-Auth-Token: {SHA1}a02258f9d970cdb9c1c2e483389f103d34134991"
  DEBUG: keystoneauth.session RESP: [201] Date: Tue, 26 Jul 2016 15:46:42 GMT 
Connection: keep-alive Content-Type: application/json; charset=UTF-8 
Content-Length: 4 X-Openstack-Request-Id: 
req-41f5dbc6-e04c-44b3-8aa8-b544a9a781e6 
  RESP BODY: null

  stack@falcon-devstack ~
  $ neutron net-show 2907e8e9-b825-4f53-bd1f-1a974edbc345

[Yahoo-eng-team] [Bug 1526719] Re: metadata should be allowed to be search option

Closing this similarly as the nova counterpart

** Changed in: python-openstackclient
   Status: New => Won't Fix

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

Title:
  metadata should be allowed to be search option

Status in OpenStack Compute (nova):
  Won't Fix
Status in python-novaclient:
  Won't Fix
Status in python-openstackclient:
  Won't Fix

Bug description:
  we allow following options to be used when filter instance, however
  metadata is not in the allow list while metadata is used by user (non-admin)

  56feb2b649cc25edd8d747806e2b9d6e0b3b8c5d added ip6 into the list and another 
microversion
  might be used to offer metadata as option

   opt_list = ('reservation_id', 'name', 'status', 'image', 'flavor',
   'ip', 'changes-since', 'all_tenants')
   if api_version_request.is_supported(req, min_version='2.5'):
   opt_list += ('ip6',)
   return opt_list

  In python-novaclient & python-openstackclient, we have to add
  'metadata' optional argument to nova list & openstack server list
  commands

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1526719/+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 1513216] Re: Mismatched keystone api version produces cryptic 'Error: Openstack'

This is mostly fixed with our transition to keystoneauth:

stevemar@ubuntu:/opt/stack/keystone$ openstack user list
Could not determine a suitable URL for the plugin
stevemar@ubuntu:/opt/stack/keystone$ export 
OS_AUTH_URL='http://172.16.240.199:5000/v3'   
stevemar@ubuntu:/opt/stack/keystone$ export OS_IDENTITY_API_VERSION='2.0' 
stevemar@ubuntu:/opt/stack/keystone$ openstack user list
Expecting to find domain in project - the server could not comply with the 
request since it is either malformed or otherwise incorrect. The client is 
assumed to be in error. (HTTP 400) (Request-ID: 
req-77424210-16af-43a4-a560-6e3e42f1112d)
stevemar@ubuntu:/opt/stack/keystone$ export OS_USER_DOMAIN_NAME="Default"
stevemar@ubuntu:/opt/stack/keystone$ export OS_PROJECT_DOMAIN_NAME="Default"
stevemar@ubuntu:/opt/stack/keystone$ openstack user list
Ignoring domain related configs project_domain_name because identity API 
version is 2.0
Ignoring domain related configs user_domain_name because identity API version 
is 2.0
Expecting to find domain in project - the server could not comply with the 
request since it is either malformed or otherwise incorrect. The client is 
assumed to be in error. (HTTP 400) (Request-ID: 
req-e5be6625-7342-4a90-95f7-f9987f4a0e0b

** Changed in: python-openstackclient
   Status: Confirmed => 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/1513216

Title:
  Mismatched keystone api version produces cryptic 'Error: Openstack'

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

Bug description:
  The 'openstack' cli tool defaults to keystone version 2.0.  When
  pointed to a v3 endpoint, it fails like this:

  $ openstack service list
  ERROR: openstack 

  This can easily be resolved by setting OS_IDENTITY_API_VERSION=3 --
  that's not obvious from the error message, though, and isn't even
  obvious from log- and code-diving.

  I propose that we actually detect the api version mismatch and error
  out with a helpful message.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1513216/+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 1391116] Re: password prompts should check for empty string

Based on Tang's findings in #18, I'm inclined to mark this as Won't Fix
for OSC.

** Changed in: python-openstackclient
   Status: Triaged => Won't Fix

** Changed in: python-keystoneclient
 Assignee: Abhishek Talwar (abhishek-talwar) => (unassigned)

** Changed in: keystone
 Assignee: Samuel de Medeiros Queiroz (samueldmq) => (unassigned)

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

Title:
  password prompts should check for empty string

Status in OpenStack Identity (keystone):
  Invalid
Status in python-keystoneclient:
  Invalid
Status in python-openstackclient:
  Won't Fix

Bug description:
  If we enter blank password for a user than it accepts it and then user
  can not log in using either older password or blank password. I
  reproduce it following way.

  1)   I entered "keystone user-password-update username" this command.
  It prompt for new password then i hit enter without giving any
  password. And during confirmation also i hit enter. Command run
  successfully without any error.

  2) I tried to log in using blank password, i was not able to log in.

  3) I tried with older password also, it did not work either.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1391116/+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 1572161] Re: Unable to request details for a specific group on non default domain

This should be fixed, refer to
https://github.com/openstack/keystone/blob/d9c6b50a3ae514e640fa13a344e59fe3649ee0ef/keystone/identity/backends/ldap/common.py#L1780-L1783

Please re-open the bug if it's not.

** Changed in: keystone
   Status: Triaged => 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/1572161

Title:
  Unable to request details for a specific group on non default domain

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  We want to get details about one specific user-group from keystone.
  The group is managed by our external LDAP server.

  The following command will list all groups, this works fine:
  curl -g -i --cacert "os.pem" -H "User-Agent: python-keystoneclient" -H 
"Accept: application/json" -H "X-Auth-Token: ***" -X GET 
"https://myopenstack:5000/v3/groups?domain_id=c867fccd207540f1818625218bbd9f50; 

  There exists an optional parameter "name" to filter the results on server 
side for only one specific group. We added this parameter and executed the 
following request:
  curl -g -i --cacert "os.pem" -H "User-Agent: python-keystoneclient" -H 
"Accept: application/json" -H "X-Auth-Token: ***" -X GET 
"https://myopenstack:5000/v3/groups?domain_id=c867fccd207540f1818625218bbd9f50=testgroup;
 

  With the second request we get a "500 Internal Server Error": An
  unexpected error prevented the server from fulfilling your request.

  Executing the same request on the the default domain succeed. Is there
  a bug when requesting detail for a specific group on a non default
  domain or a LDAP server?

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1572161/+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 1608726] [NEW] BadRequest during floating ip assignment

2016-08-01 Thread Inessa Vasilevskaya

Public bug reported:

Seen on mos 10, 1 controller/1 compute.

Not very difficult to trigger, though isn't reproduced on every run (got
3 hits in ~15 runs).

The error was seen while running this script (sorry about my bash
http://paste.openstack.org/show/545220/) on freshly deployed mos.

Steps to reproduce:
1). create floating id with nova floating-ip-create
2). boot a VM
3). right afterwards (not waiting for the VM to reach active state) assign a 
floating ip via nova floating-ip-associate

In ~20% of runs the following error was received: 
ERROR (BadRequest): No nw_info cache associated with instance (HTTP 400) 
(Request-ID: req-907e70c0-b6f7-4368-ae66-c02dd216000d)

The VM didn't get floating ip during unsuccessful runs.

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

Title:
  BadRequest during floating ip assignment

Status in OpenStack Compute (nova):
  New

Bug description:
  Seen on mos 10, 1 controller/1 compute.

  Not very difficult to trigger, though isn't reproduced on every run
  (got 3 hits in ~15 runs).

  The error was seen while running this script (sorry about my bash
  http://paste.openstack.org/show/545220/) on freshly deployed mos.

  Steps to reproduce:
  1). create floating id with nova floating-ip-create
  2). boot a VM
  3). right afterwards (not waiting for the VM to reach active state) assign a 
floating ip via nova floating-ip-associate

  In ~20% of runs the following error was received: 
  ERROR (BadRequest): No nw_info cache associated with instance (HTTP 400) 
(Request-ID: req-907e70c0-b6f7-4368-ae66-c02dd216000d)

  The VM didn't get floating ip during unsuccessful runs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1608726/+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 1608691] Re: exception translation for pymysql "Lock wait timeout exceeded" broken

2016-08-01 Thread Kevin Benton

Added neutron because this exception was observed in the gate:
http://logs.openstack.org/43/298443/4/check/gate-grenade-dsvm-neutron-
dvr-
multinode/56112e8/logs/old/screen-q-svc.txt.gz?level=TRACE#_2016-07-31_00_21_14_938

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

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

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

** Changed in: neutron
   Status: New => 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/1608691

Title:
  exception translation for pymysql "Lock wait timeout exceeded" broken

Status in neutron:
  Confirmed
Status in oslo.db:
  New

Bug description:
  It looks like the classifier for "lock wait timeout exceeded" as a
  DBDeadlock is not correct for pymysql. Snippet of traceback showing it
  as the generic DBError:

  2016-07-31 00:21:14.938 4145 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/err.py", line 120, in 
raise_mysql_exception
  2016-07-31 00:21:14.938 4145 ERROR neutron.api.v2.resource 
_check_mysql_exception(errinfo)
  2016-07-31 00:21:14.938 4145 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/err.py", line 115, in 
_check_mysql_exception
  2016-07-31 00:21:14.938 4145 ERROR neutron.api.v2.resource raise 
InternalError(errno, errorvalue)
  2016-07-31 00:21:14.938 4145 ERROR neutron.api.v2.resource DBError: 
(pymysql.err.InternalError) (1205, u'Lock wait timeout exceeded; try restarting 
transaction') [SQL: u'SELECT ipavailabilityranges.allocation_pool_id AS 
ipavailabilityranges_allocation_pool_id, ipavailabilityranges.first_ip AS 
ipavailabilityranges_first_ip, ipavailabilityranges.last_ip AS 
ipavailabilityranges_last_ip \nFROM ipavailabilityranges INNER JOIN 
ipallocationpools ON ipallocationpools.id = 
ipavailabilityranges.allocation_pool_id \nWHERE ipallocationpools.subnet_id = 
%(subnet_id_1)s \n LIMIT %(param_1)s FOR UPDATE'] [parameters: {u'param_1': 1, 
u'subnet_id_1': u'344485c9-e600-40c0-8acf-d9ba98dacf99'}]

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1608691/+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 1570049] Re: Tox ignores following docstrings error codes D202, D203, D205, D400, D401

This is not an issue in the latest tox.ini
https://github.com/openstack/keystone/blob/master/tox.ini

** Changed in: keystone
   Status: Triaged => 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/1570049

Title:
  Tox ignores following docstrings error codes D202,D203,D205,D400,D401

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  Currently tox ignores the following docstring errors:

  D202: No blank lines allowed after docstring.
  D203: 1 blank required before class docstring.
  D205: Blank line required between one-line summary and description.
  D400: First line should end with a period.
  D401: First line should be in imperative mood.

  These ignores[1] must be removed and make keystone compliant.

  1)https://github.com/openstack/keystone/blob/master/tox.ini#L124-L128

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1570049/+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 1362309] Re: Creating an endpoint with an invalid service_id returns the wrong error code

This would break backwards compatibility. See dolphs's comment in #2.
We're stuck with 404's.

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

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

Title:
  Creating an endpoint with an invalid service_id returns the wrong
  error code

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  When creating or updating an endpoint with an invalid service_id
  specified the server returns a 404 instead of a 400. While it's true
  that the service can't be found, that's not the resource the client is
  attempting to access.  This is misleading.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1362309/+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 1524515] Re: get sql-based Domain-specific driver configuration with incorrect group in URL, expected response 404, actual 403

No movement on this issue and I've explained my reasoning in comment #4.
We won't be re-writing response codes now since that's backwards
compatible.

** Changed in: keystone
   Status: Triaged => 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/1524515

Title:
  get sql-based Domain-specific driver configuration with incorrect
  group in URL, expected response 404, actual 403

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  get sql-based Domain-specific driver configuration with incorrect
  group in URL, expected response 404, actual 403:

  With sql-based Domain-specific driver configuration set up connection to a 
openldap or  ad backend for a domain,
  if an invalid/typo group name (e.g. [identity2], instead of [identity]) in 
the request url for this domain is provided,  we expect the response code 404 
(not found), but actual is 403 (forbidden).  The user actually has the 
permission to access the configuration. 403 forbidden seems misleading. 

  Example:
  ~$ curl -k -H "X-Auth-Token:ADMIN" -XDELETE 
http://localhost:35357/v3/domains/6a006689702640ba92d5e536b238e893/config/invalidgroup

  Actual:
  {"error": {"message": "Invalid domain specific configuration: Group identity2 
is not supported for domain specific configurations", "code": 403, "title": 
"Forbidden"}}

  Expected:
  ~$ curl -k -H "X-Auth-Token:ADMIN" -XDELETE 
http://localhost:35357/v3/domains/6a006689702640ba92d5e536b238e893/config/identity2
  {"error": {"message": "Invalid domain specific configuration: Group identity2 
is not supported for domain specific configurations", "code": 404, "title": 
"Not Found"}}

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1524515/+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 1324023] Re: Can't consume trusts on domains

Trusts were not designed to support domain delegation. This is not a
bug, but a request for enhancement. Please create a specification in
keystone-specs that outlines a use case for this enhancement. I would
think delegating permission to a user across an entire domain would lead
to all sorts of security issues.

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

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

Title:
  Can't consume trusts on domains

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  When trying to create a trust on a project, I always get a "forbidden"
  error. When creating a trust on a domain, the trust is created
  successfully but then I get this error when trying to use it:

  "Expecting to find id or name in project. The server could not comply
  with the request since it is either malformed or otherwise incorrect.
  The client is assumed to be in error."

  To recreate:
  1) Create a domain called dom1:
  curl -X POST -H "X-Auth-Token:$MYTOKEN" -H "Content-type:application/json" 
http://localhost:35357/v3/domains -d '{"domain": {"name": "dom1", "enabled": 
true}}'

  2) Create a user called dom1admin:
  curl -X POST -H "X-Auth-Token:$MYTOKEN" -H "Content-type:application/json" 
http://localhost:35357/v3/users -d '{"user": {"name": "dom1admin", "password": 
"dom1admin", "domain_id": "53f39ebfa9b44f4ab2543a151ac29d3f", "enabled": true}}'

  3) Give dom1admin the "admin" role on the domain:
  curl -X PUT -H "X-Auth-Token:$MYTOKEN" 
http://localhost:35357/v3/domains/53f39ebfa9b44f4ab2543a151ac29d3f/users/09d1e1931f564952abb7a4f515a28f35/roles/d43cb0756e2848ee800bbd5d90e207d1

  4) With a token of dom1admin, create a project called dom1proj1:
   curl -X POST -H "X-Auth-Token:$TOKEN" -H "Content-type:application/json" 
http://localhost:35357/v3/projects -d '{"project": {"name": "dom1proj1", 
"domain_id": "53f39ebfa9b44f4ab2543a151ac29d3f", "enabled": true}}'

  5) Create a user called dom1proj1admin:
  curl -X POST -H "X-Auth-Token:$TOKEN" -H "Content-type:application/json" 
http://localhost:35357/v3/users -d '{"user": {"name": "dom1proj1admin", 
"password": "dom1proj1admin", "domain_id": "53f39ebfa9b44f4ab2543a151ac29d3f", 
"enabled": true}}'

  6) Grant admin rights to dom1proj1admin:
  curl -X PUT -H "X-Auth-Token:$MYTOKEN" 
http://localhost:35357/v3/projects/8ec21ac3aa2c4d0f961ea3df6e77514a/users/308402875e10487dbf59941b20abc84c/roles/d43cb0756e2848ee800bbd5d90e207d1

  7) Repeat steps 4-6 to create dom1proj2, dom1proj2admin, and role
  granting.

  8) With a token of dom1proj1admin, create a trust to give admin rights to 
dom1proj2admin:
  curl -X POST -H "X-Auth-Token:$TOKEN" -H "Content-type:application/json" 
http://localhost:35357/v3/OS-TRUST/trusts -d '{"trust": {"expires_at": 
"2015-02-27T18:30:59.99Z", "impersonation": true, "project_id": 
"8ec21ac3aa2c4d0f961ea3df6e77514a", "role": [{"name": "admin"}], 
"trustee_user_id": "3e919ca95be540ffb3e132be5fc367f2", "trustor_user_id": 
"308402875e10487dbf59941b20abc84c"}}'

  You get:
  {
  "error": {
  "code": 403,
  "message": "You are not authorized to perform the requested action.",
  "title": "Forbidden"
  }
  }

  I tried different rules in the policy file but couldn't get this to
  work.

  9) With a token of dom1admin, give a trust on the domain to user 
dom1proj1admin:
  curl -X POST -H "X-Auth-Token:$TOKEN" -H "Content-type:application/json" 
http://localhost:35357/v3/OS-TRUST/trusts -d '{"trust": {"expires_at": 
"2015-02-27T18:30:59.99Z", "impersonation": true, "domain_id": 
"3e919ca95be540ffb3e132be5fc367f2", "role": [{"name": "admin"}], 
"trustee_user_id": "3e919ca95be540ffb3e132be5fc367f2", "trustor_user_id": 
"09d1e1931f564952abb7a4f515a28f35"}}'

  Trust is created:
  {
  "trust": {
  "domain_id": "3e919ca95be540ffb3e132be5fc367f2",
  "expires_at": "2015-02-27T18:30:59.99Z",
  "id": "6c6b7e4067d64df2acb9a9e33579fbc9",
  "impersonation": true,
  "links": {
  "self": 
"http://localhost:35357/v3/OS-TRUST/trusts/6c6b7e4067d64df2acb9a9e33579fbc9;
  },
  "project_id": null,
  "remaining_uses": null,
  "role": [
  {
  "name": "admin"
  }
  ],
  "roles": [],
  "roles_links": {
  "next": null,
  "previous": null,
  "self": 
"http://localhost:35357/v3/OS-TRUST/trusts/6c6b7e4067d64df2acb9a9e33579fbc9/roles;
  },
  "trustee_user_id": "3e919ca95be540ffb3e132be5fc367f2",
  "trustor_user_id": "09d1e1931f564952abb7a4f515a28f35"
  }
  }

  10) With a token of dom1proj1admin, try to consume the trust:
  {
  "auth": {
  "identity": {
  "methods": [
  "token"

[Yahoo-eng-team] [Bug 1376937] Re: No way to prevent duplicates in endpoints

This would break backwards compatibility.

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

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

Title:
  No way to prevent duplicates in endpoints

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  Keystone doesn't provide a way to ensure that we do not create
  duplicate endpoints. Imagine two concurrent workers attempting to
  create a keystone endpoint. There are no unique constraints for
  endpoints besides the id, but the id cannot be set externally, so
  there isn't an easy way to ensure only one gets created without a
  global lock

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1376937/+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 1592043] Re: os-brick 1.4.0 increases volume setup failure rates

Reviewed:  https://review.openstack.org/329769
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=4a8f2b0d44ee10dfac2d3d828cd9dc574d5ddbb2
Submitter: Jenkins
Branch:master

commit 4a8f2b0d44ee10dfac2d3d828cd9dc574d5ddbb2
Author: Angus Lees 
Date:   Wed Jun 15 15:46:38 2016 +1000

Initialise oslo.privsep early in main

Any process using oslo.privsep should now initialise the library before
first use with things like the rootwrap command to use.

This should be done near the top of main() in any command that expects
to make privileged calls via oslo.privsep (eg: nova-compute, and not
nova-api).

See I3ea73e16b07a870629e7d69e897f2524d7068ae8 for the corresponding
change in oslo.privsep.

Change-Id: I3a52f762deb176fe9201b2a0f0da363057f8aaec
Depends-On: I52259e2023e277e8fd62be5df4fd7f799e9b36d7
Closes-Bug: #1592043


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

Title:
  os-brick 1.4.0 increases volume setup failure rates

Status in OpenStack Compute (nova):
  Fix Released
Status in os-brick:
  In Progress
Status in oslo.privsep:
  New

Bug description:
  Since merging upper constraints 1.4.0 into upper-constraints, the
  multinode grenade jobs are hitting a nearly 1/3 failure rate on boot
  from volume scenarios around volume setup. This would be on Newton
  code using Mitaka configs.

  Representative failures are of the following form:
  http://logs.openstack.org/71/327971/5/gate/gate-grenade-dsvm-neutron-
  
multinode/f2690e3/logs/new/screen-n-cpu.txt.gz?level=WARNING#_2016-06-13_15_22_59_095

  The 1/3 failure rate is suspicious, and in the past has often hinted
  towards a race condition interacting between parallel API requests.

  The failure rate increase can be seen here -
  http://tinyurl.com/zrq35e8

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1592043/+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 1546834] Re: The deletion of an LDAP domain in keystone when write enabled should not clear the LDAP database

Write support is deprecated and will be removed in 6 weeks. Marking this
as Opinion.

** Changed in: keystone
   Status: Triaged => Opinion

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

Title:
   The deletion of an LDAP domain in keystone when write enabled should
  not clear the LDAP database

Status in OpenStack Identity (keystone):
  Opinion

Bug description:
  Description of problem:
  Testing multi domain support in RHOS. The deletion of this domain when write 
enabled cleared the LDAP database entirely. Thankfully this was done in a lab, 
because LDAP was a total loss. 

  Version-Release number of selected component (if applicable):

  # rpm -qa | grep packstack
  openstack-packstack-puppet-2015.1-0.14.dev1589.g1d6372f.el7ost.noarch
  openstack-packstack-2015.1-0.14.dev1589.g1d6372f.el7ost.noarch

  # rpm -qa | grep keystone
  python-keystoneclient-1.3.0-2.el7ost.noarch
  python-keystone-2015.1.2-2.el7ost.noarch
  openstack-keystone-2015.1.2-2.el7ost.noarch
  python-keystonemiddleware-1.5.1-1.el7ost.noarch

  How reproducible:
  Assuming always? I was only able to do this once. 

  
  Steps to Reproduce:
  1. Enable multi domain support in keystone, ensure the following is in 
/etc/keystone.conf

  [identity]
  domain_specific_drivers_enabled = true 
  domain_config_dir = /etc/keystone/domains
  #default_domain_id = 7d9bed61b1564f2289296a4e9241482d

  2. Then add an LDAP domain and ensure that writes are permitted.

  vim /etc/keystone/domains/keystone.laboratory.conf

  [ldap]
  url=ldap://auth.lab.runlevelone.lan
  user=uid=keystone,cn=users,cn=accounts,dc=lab,dc=runlevelone,dc=lan
  password=xxx
  suffix=ccn=accounts,dc=lab,dc=runlevelone,dc=lan
  user_tree_dn=cn=users,cn=accounts,dc=lab,dc=runlevelone,dc=lan
  user_objectclass=person
  user_id_attribute=uid
  user_name_attribute=uid
  user_mail_attribute=mail
  user_allow_create=true
  user_allow_update=true
  user_allow_delete=true
  group_tree_dn=cn=groups,cn=accounts,dc=lab,dc=runlevelone,dc=lan
  group_objectclass=groupOfNames
  group_id_attribute=cn
  group_name_attribute=cn
  group_member_attribute=member
  group_desc_attribute=description
  group_allow_create=true
  group_allow_update=true
  group_allow_delete=true
  user_enabled_attribute=nsAccountLock
  user_enabled_default=false
  user_enabled_invert=true

  [identity]
  driver = keystone.identity.backends.ldap.Identity

  
  3. Remove the domain, using 'openstack domain delete #domain_id' 


  Actual results:
  Clears LDAP database, 
cn=users/groups,cn=accounts,dc=lab,dc=runlevelone,dc=lan was completely empty

  
  Expected results:
  Does not delete users on removal or prompt "THIS WILL DELETE ALL USERS, DO 
YOU WANT TO PROCEED"

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1546834/+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 1419128] Re: Unsupported mix of LDAP & SQL between backends should error cleanly

We've removed LDAP support for resource, which seems clear enough.

** Changed in: keystone
   Status: Triaged => 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/1419128

Title:
  Unsupported mix of LDAP & SQL between backends should error cleanly

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  Although we now make it clear in our documentation and code comments
  that we do not support an LDAP resources/assignment driver if the
  identity driver is not also LDAP (see:
  https://bugs.launchpad.net/keystone/+bug/1415169) - we should, in
  fact, also detect such a condition on startup and fail with a clear
  error message.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1419128/+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 1259827] Re: keystone execute SQL statements so many times?

I am marking this as fix released based on
https://review.openstack.org/#/c/272007/ merging. We can open separate
bugs for new issues but having a large sweeping bug like this one will
cause us to never close it.

** Changed in: keystone
   Status: Triaged => Fix Released

** Changed in: keystone
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

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

Title:
  keystone execute SQL statements so many times?

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  When I login horizon,I found keystone query database tables many
  times.

  From keystone.log,I can see the steps like this: 
  step1:keystone recieve request like this :{"auth": 
{"passwordCredentials":{"username": "admin", "password":"*"}}} step2:keystone 
query user table by username and domain id 
  stpe3:keystone query user table by user id 
  step4:keystone query user table by user id 
  step5:keystone query user_group_membership table 
  step6:keystone query domain table 
  step7:keystone create a new token and insert it into token table

  From above steps,we can see keystone query the user table tree times,I
  think once is enough. Especially the step3 and step4 are repeated.

  So many sql statments will reduce the performance of database.

  Here are the keystone logs:

  2013-12-11 09:41:21DEBUG [keystone.common.wsgi] {"auth": 
{"passwordCredentials":{"username": "admin", "password":"***"}}}
  2013-12-11 09:41:21DEBUG [keystone.common.wsgi]
  2013-12-11 09:41:21DEBUG [keystone.common.wsgi] arg_dict: {}
  2013-12-11 09:41:21 INFO [sqlalchemy.engine.base.Engine] SELECT user.id 
AS user_id, user.name AS user_name, user.domain_id AS user_domain_id, 
user.password AS user_password, user.enabled AS user_enabled, user.extra AS 
user_extra
  FROM user
  WHERE user.name = %s AND user.domain_id = %s
  2013-12-11 09:41:21 INFO [sqlalchemy.engine.base.Engine] ('admin', 
'default')
  2013-12-11 09:41:21 INFO [sqlalchemy.engine.base.Engine] SELECT user.id 
AS user_id, user.name AS user_name, user.domain_id AS user_domain_id, 
user.password AS user_password, user.enabled AS user_enabled, user.extra AS 
user_extra
  FROM user
  WHERE user.id = %s
   LIMIT %s
  2013-12-11 09:41:21 INFO [sqlalchemy.engine.base.Engine] 
('5463d155acf642f1b0354036f7a8a84b', 1)
  2013-12-11 09:41:21 INFO [passlib.registry] registered crypt handler 
'sha512_crypt': 
  2013-12-11 09:41:21 INFO [sqlalchemy.engine.base.Engine] SELECT user.id 
AS user_id, user.name AS user_name, user.domain_id AS user_domain_id, 
user.password AS user_password, user.enabled AS user_enabled, user.extra AS 
user_extra
  FROM user
  WHERE user.id = %s
   LIMIT %s
  2013-12-11 09:41:21 INFO [sqlalchemy.engine.base.Engine] 
('5463d155acf642f1b0354036f7a8a84b', 1)
  2013-12-11 09:41:21 INFO [sqlalchemy.engine.base.Engine] SELECT 
user_group_membership.user_id AS user_group_membership_user_id, 
user_group_membership.group_id AS user_group_membership_group_id
  FROM user_group_membership
  WHERE user_group_membership.user_id = %s
  2013-12-11 09:41:21 INFO [sqlalchemy.engine.base.Engine] 
('5463d155acf642f1b0354036f7a8a84b',)
  2013-12-11 09:41:21 INFO [sqlalchemy.engine.base.Engine] SELECT domain.id 
AS domain_id, domain.name AS domain_name, domain.enabled AS domain_enabled, 
domain.extra AS domain_extra
  FROM domain
  WHERE domain.id = %s
   LIMIT %s
  2013-12-11 09:41:21 INFO [sqlalchemy.engine.base.Engine] ('default', 1)
  2013-12-11 09:41:21 INFO [sqlalchemy.engine.base.Engine] BEGIN (implicit)
  2013-12-11 09:41:21 INFO [sqlalchemy.engine.base.Engine] INSERT INTO 
token (id, expires, extra, valid, user_id, trust_id) VALUES (%s, %s, %s, %s, 
%s, %s)
  2013-12-11 09:41:21 INFO [sqlalchemy.engine.base.Engine] 
('903e4d7e80573b2ec4a6dbc7a285b219', datetime.datetime(2013, 12, 12, 1, 41, 21, 
845497), '{"key": 
"MIICbgYJKoZIhvcNAQcCoIICXzCCAlsCAQExCTAHBgUrDgMCGjCCAUcGCSqGSIb3DQEHAaCCATgEggE0eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0xMi0xMVQwMTo0MToyMS44NDg1MjEiLCAiZXhwaXJlcyI6ICIyMDEzLTEyLTEyVDAxOjQxOjIxWiIsICJpZCI6ICJwbGFjZWhvbGRlciJ9LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogImFkbWluIiwgInJvbGVzX2xpbmtzIjogW10sICJpZCI6ICI1NDYzZDE1NWFjZjY0MmYxYjAzNTQwMzZmN2E4YTg0YiIsICJyb2xlcyI6IFtdLCAibmFtZSI6ICJhZG1pbiJ9LCAibWV0YWRhdGEiOiB7ImlzX2FkbWluIjogMCwgInJvbGVzIjogW119fX0xgf8wgfwCAQEwXDBXMQswCQYDVQQGEwJVUzEOMAwGA1UECBMFVW5zZXQxDjAMBgNVBAcTBVVuc2V0MQ4wDAYDVQQKEwVVbnNldDEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tAgEBMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIGAKxDfbLnxLg+pZ2aTM28JIFiZLfGbubbiM+Edg9wbE+wV5uB0C7Q8nHLQxaMrRtYmOUmLLPnvp8uBdEcxWtnTazgt5k1i4LOQyn+teWGcIQeyoC8kl4eNmIgBeT+PqFVKpss4uBAaVlXIuqVUJXBRQIY6GhrKz3BUnVl8+w4keTY=
 ", "user": {"email": "ad...@zte.com", "tenantId": 
"d5030c82dca9485082920b9d123618f4",

[Yahoo-eng-team] [Bug 1544721] Re: Policy for listing service providers requires admin

** Changed in: keystone
   Status: Triaged => 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/1544721

Title:
  Policy for listing service providers requires admin

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  When creating a v3 keystoneclient using non admin credentials I'm able
  to get the list of service providers from the service catalog, but the
  policy doesn't allow to list or get service providers by default.

  >>> ksclient2.service_catalog.catalog[u'service_providers']
  [{u'sp_url': u'http://xxx.xxx.xxx.xxx:5000/Shibboleth.sso/SAML2/ECP', 
u'auth_url': 
u'http://xxx.xxx.xxx.xxx:35357/v3/OS-FEDERATION/identity_providers/keystone-idp/protocols/saml2/auth',
 u'id': u'keystone-sp'}]

  >>> ksclient2.federation.service_providers.list()
  Traceback (most recent call last):
File "", line 1, in 
File 
"/usr/local/lib/python2.7/dist-packages/keystoneclient/v3/contrib/federation/service_providers.py",
 line 76, in list
  return super(ServiceProviderManager, self).list(**kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/base.py", line 
75, in func
  return f(*args, **new_kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/base.py", line 
388, in list
  self.collection_key)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/base.py", line 
124, in _list
  resp, body = self.client.get(url, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/adapter.py", 
line 170, in get
  return self.request(url, 'GET', **kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/adapter.py", 
line 206, in request
  resp = super(LegacyJsonAdapter, self).request(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/adapter.py", 
line 95, in request
  return self.session.request(url, method, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/utils.py", line 
337, in inner
  return func(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py", 
line 405, in request
  raise exceptions.from_response(resp, method, url)
  keystoneauth1.exceptions.http.Forbidden: You are not authorized to perform 
the requested action: identity:list_service_providers (Disable debug mode to 
suppress these details.) (HTTP 403) (Request-ID: 
req-485c64e6-5de1-4470-9439-e05275a350fa)

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1544721/+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 1572202] Re: testresources needs to be explicitly required for tests

bumping tox and global requirements fixed this issue

** Changed in: keystone
   Status: Triaged => Fix Released

** Changed in: keystone
Milestone: None => newton-1

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

Title:
  testresources needs to be explicitly required for tests

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  I get the following traceback when trying to run tests from master:

  Failed to import test module: keystone.tests.unit.test_sql_upgrade
  Traceback (most recent call last):
File 
"/opt/stack/keystone.old/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 456, in _find_test_path
  module = self._get_module_from_name(name)
File 
"/opt/stack/keystone.old/.tox/py27/local/lib/python2.7/site-packages/unittest2/loader.py",
 line 395, in _get_module_from_name
  __import__(name)
File "keystone/tests/unit/test_sql_upgrade.py", line 42, in 
  from oslo_db.sqlalchemy import test_base
File 
"/opt/stack/keystone.old/.tox/py27/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/test_base.py",
 line 17, in 
  import testresources
  ImportError: No module named testresources
  The test run didn't actually run any tests

  Explicitly requiring testresources for tests fixes the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1572202/+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 1607398] Re: DVR, Floating IPs are not working. Failed sending gratuitous ARP

2016-08-01 Thread Brian Haley

** Changed in: neutron
   Status: Incomplete => 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/1607398

Title:
  DVR, Floating IPs are not working. Failed sending gratuitous ARP

Status in neutron:
  Invalid

Bug description:
  Hello, I'm trying to use DVR and floating IPs, but it does not work.
  When I'm trying to associate a floating IP with VM, I see on the compute node:

  2016-07-28 14:26:31.893 125513 DEBUG neutron.agent.linux.utils [-] Running 
command (rootwrap daemon): ['ip', 'netns', 'exec', 
'fip-4f2774d1-dfb8-4833-8374-806e1fc40827', 'arping', '-A', '-I', 
'fg-86481da8-4c', '-c', '3', '-w', '4.5', '172.16.48.6'] 
execute_rootwrap_daemon 
/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:100
  2016-07-28 14:26:31.912 125513 ERROR neutron.agent.linux.utils [-] Exit code: 
2; Stdin: ; Stdout: ; Stderr: bind: Cannot assign requested address

  2016-07-28 14:26:31.912 125513 ERROR neutron.agent.linux.ip_lib [-] Failed 
sending gratuitous ARP to 172.16.48.6 on fg-86481da8-4c in namespace 
fip-4f2774d1-dfb8-4833-8374-806e1fc40827
  2016-07-28 14:26:31.912 125513 ERROR neutron.agent.linux.ip_lib Traceback 
(most recent call last):
  2016-07-28 14:26:31.912 125513 ERROR neutron.agent.linux.ip_lib   File 
"/usr/lib/python2.7/site-packages/neutron/agent/linux/ip_lib.py", line 1040, in 
_arping
  2016-07-28 14:26:31.912 125513 ERROR neutron.agent.linux.ip_lib 
ip_wrapper.netns.execute(arping_cmd, check_exit_code=True)
  2016-07-28 14:26:31.912 125513 ERROR neutron.agent.linux.ip_lib   File 
"/usr/lib/python2.7/site-packages/neutron/agent/linux/ip_lib.py", line 927, in 
execute
  2016-07-28 14:26:31.912 125513 ERROR neutron.agent.linux.ip_lib 
log_fail_as_error=log_fail_as_error, **kwargs)
  2016-07-28 14:26:31.912 125513 ERROR neutron.agent.linux.ip_lib   File 
"/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py", line 140, in 
execute
  2016-07-28 14:26:31.912 125513 ERROR neutron.agent.linux.ip_lib raise 
RuntimeError(msg)
  2016-07-28 14:26:31.912 125513 ERROR neutron.agent.linux.ip_lib RuntimeError: 
Exit code: 2; Stdin: ; Stdout: ; Stderr: bind: Cannot assign requested address
  2016-07-28 14:26:31.912 125513 ERROR neutron.agent.linux.ip_lib 
  2016-07-28 14:26:31.912 125513 ERROR neutron.agent.linux.ip_lib 
  2016-07-28 14:26:31.948 125513 DEBUG oslo_messaging._drivers.amqpdriver [-] 
received reply msg_id: 67908aabc9bd446493cd22af8cccbd59 __call__ 
/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:302
  2016-07-28 14:26:31.949 125513 DEBUG neutron.agent.linux.utils [-] Running 
command (rootwrap daemon): ['ip', 'netns', 'exec', 
'fip-4f2774d1-dfb8-4833-8374-806e1fc40827', 'ip', '-o', 'link', 'show', 
'fpr-a5e261f2-9'] execute_rootwrap_daemon 
/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:100

  
  [root@node13 ~]# sysctl net.ipv4.ip_nonlocal_bind
  net.ipv4.ip_nonlocal_bind = 1

  [root@node13 ~]# ip netns exec fip-4f2774d1-dfb8-4833-8374-806e1fc40827 
sysctl net.ipv4.ip_nonlocal_bind
  net.ipv4.ip_nonlocal_bind = 1

  Remote ping is not working:
  [root@node13 ~]# ping -c2 172.16.48.6
  PING 172.16.48.6 (172.16.48.6) 56(84) bytes of data.
  ^C
  --- 172.16.48.6 ping statistics ---
  2 packets transmitted, 0 received, 100% packet loss, time 999ms

  Ping into the namespace is working:
  [root@node13 ~]# ip netns
  fip-4f2774d1-dfb8-4833-8374-806e1fc40827
  qrouter-a5e261f2-991c-497c-adcd-b1e9e1a8a001

  [root@node13 ~]# ip netns exec fip-4f2774d1-dfb8-4833-8374-806e1fc40827 ping 
-c2 172.16.48.6
  PING 172.16.48.6 (172.16.48.6) 56(84) bytes of data.
  64 bytes from 172.16.48.6: icmp_seq=1 ttl=63 time=0.290 ms
  64 bytes from 172.16.48.6: icmp_seq=2 ttl=63 time=0.260 ms

  --- 172.16.48.6 ping statistics ---
  2 packets transmitted, 2 received, 0% packet loss, time 1000ms
  rtt min/avg/max/mdev = 0.260/0.275/0.290/0.015 ms

  Additional information:
  [root@node13 ~]# ip netns exec fip-4f2774d1-dfb8-4833-8374-806e1fc40827 ip 
addr
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host 
 valid_lft forever preferred_lft forever
  9: fpr-a5e261f2-9:  mtu 1500 qdisc 
pfifo_fast state UP qlen 1000
  link/ether ce:cd:c7:4d:b8:c2 brd ff:ff:ff:ff:ff:ff link-netnsid 0
  inet 169.254.126.51/31 scope global fpr-a5e261f2-9
 valid_lft forever preferred_lft forever
  inet6 fe80::cccd:c7ff:fe4d:b8c2/64 scope link 
 valid_lft forever preferred_lft forever
  333: fg-86481da8-4c:  mtu 1450 qdisc noqueue 
state UNKNOWN 
  link/ether fa:16:3e:3b:ac:ac brd ff:ff:ff:ff:ff:ff
  inet 172.16.48.4/22 brd 172.16.51.255 scope global

[Yahoo-eng-team] [Bug 1605277] Re: [IPAM] 'Internal' ipam driver does not allow to delete all pools on subnet update

Reviewed:  https://review.openstack.org/345498
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=de2a70165c351abcc1266b79bae46fcd8ce68e59
Submitter: Jenkins
Branch:master

commit de2a70165c351abcc1266b79bae46fcd8ce68e59
Author: Pavel Bondar 
Date:   Thu Jul 21 17:51:54 2016 +0300

Fix updating allocation_pools on subnet update

Reference IPAM driver skipped subnet_update processing
if allocation_pools in subnet request are blank.

Built-in ipam implementation allows to update allocation pools
to blank value (i.e. clean up allocation pools for subnet).
To make Reference ipam driver consistent with built-in ipam
implementation allocation_pool check was removed.

Included UT to verify that allocation pools can be updated to blank
value now.

Change-Id: I0654e46d4bc60f6cf51ffddeead238dd4f064db2
Closes-Bug: #1605277


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

Title:
  [IPAM] 'Internal' ipam driver does not allow to delete all pools on
  subnet update

Status in neutron:
  Fix Released

Bug description:
  During investigation UT test failure
  'test_port_update_deferred_allocation_no_ips' in [1] I found that
  attempt to update subnet providing blank ([]) allocation pools leads
  to silent ignoring this action on ipam driver side.

  Reference ipam driver skips processing of the update request because of 
condition
  "if not subnet_request.allocation_pools" in [2], which is too strict and
  does not allow to clean up allocation pools on subnet update.

  It is a because cleaning up allocation pools is a valid user action
  and built-in ipam implementation allows to do it.

  Expected behavior:
  Reference ipam driver should work the same as a built-in implementation and 
should allow to remove 'allocation_pools' on subnet update.

  [1] 
http://logs.openstack.org/23/181023/89/check/gate-neutron-python27/2071f1d/testr_results.html.gz
  [2] 
https://github.com/openstack/neutron/blob/38a080aca37197ff9c5464a3bc9981e684decee6/neutron/ipam/drivers/neutrondb_ipam/driver.py#L294

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1605277/+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 1608653] [NEW] Installing reqs from test-requirements.txt using pip fails due to missing lib package for psycopg2

2016-08-01 Thread Gage Hugo

Public bug reported:

When setting up a development environment following the instructions
here:

http://docs.openstack.org/developer/keystone/devref/development.environment.html

On Ubuntu 16.04.1 when installing dependencies from test-
requirements.txt using pip, the installation fails when it tries to
install psycopg2:

Collecting psycopg2>=2.5; extra == "postgresql" (from 
oslo.db[fixtures,mysql,postgresql]>=4.1.0->-r test-requirements.txt (line 13))
  Downloading psycopg2-2.6.2.tar.gz (376kB)
100% || 378kB 769kB/s
Complete output from command python setup.py egg_info:
running egg_info
creating pip-egg-info/psycopg2.egg-info
writing pip-egg-info/psycopg2.egg-info/PKG-INFO
writing top-level names to pip-egg-info/psycopg2.egg-info/top_level.txt
writing dependency_links to 
pip-egg-info/psycopg2.egg-info/dependency_links.txt
writing manifest file 'pip-egg-info/psycopg2.egg-info/SOURCES.txt'
warning: manifest_maker: standard file '-c' not found

Error: pg_config executable not found.

Please add the directory containing pg_config to the PATH
or specify the full executable path with the option:

python setup.py build_ext --pg-config /path/to/pg_config build
...

or with the pg_config option in 'setup.cfg'.


Command "python setup.py egg_info" failed with error code 1 in 
/tmp/pip-build-j460mO/psycopg2/


Googling this error brings you to this fix from stackoverflow:

http://stackoverflow.com/questions/11618898/pg-config-executable-not-
found

Which simply involves installing the libpq-dev package.  This fixes the
problem and the rest of test-requirements.txt are installed fine.

Recommend adding libpg-dev (Ubuntu/Debian) along with other package
managers to the list of dependencies to install before using pip:

http://docs.openstack.org/developer/keystone/devref/development.environment.html
#installing-dependencies

** Affects: keystone
 Importance: Undecided
 Assignee: Gage Hugo (gagehugo)
 Status: New


** Tags: documentation

** Changed in: keystone
 Assignee: (unassigned) => Gage Hugo (gagehugo)

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

Title:
  Installing reqs from test-requirements.txt using pip fails due to
  missing lib package for psycopg2

Status in OpenStack Identity (keystone):
  New

Bug description:
  When setting up a development environment following the instructions
  here:

  
http://docs.openstack.org/developer/keystone/devref/development.environment.html

  On Ubuntu 16.04.1 when installing dependencies from test-
  requirements.txt using pip, the installation fails when it tries to
  install psycopg2:

  Collecting psycopg2>=2.5; extra == "postgresql" (from 
oslo.db[fixtures,mysql,postgresql]>=4.1.0->-r test-requirements.txt (line 13))
Downloading psycopg2-2.6.2.tar.gz (376kB)
  100% || 378kB 769kB/s
  Complete output from command python setup.py egg_info:
  running egg_info
  creating pip-egg-info/psycopg2.egg-info
  writing pip-egg-info/psycopg2.egg-info/PKG-INFO
  writing top-level names to pip-egg-info/psycopg2.egg-info/top_level.txt
  writing dependency_links to 
pip-egg-info/psycopg2.egg-info/dependency_links.txt
  writing manifest file 'pip-egg-info/psycopg2.egg-info/SOURCES.txt'
  warning: manifest_maker: standard file '-c' not found

  Error: pg_config executable not found.

  Please add the directory containing pg_config to the PATH
  or specify the full executable path with the option:

  python setup.py build_ext --pg-config /path/to/pg_config build
  ...

  or with the pg_config option in 'setup.cfg'.

  
  Command "python setup.py egg_info" failed with error code 1 in 
/tmp/pip-build-j460mO/psycopg2/

  
  Googling this error brings you to this fix from stackoverflow:

  http://stackoverflow.com/questions/11618898/pg-config-executable-not-
  found

  Which simply involves installing the libpq-dev package.  This fixes
  the problem and the rest of test-requirements.txt are installed fine.

  Recommend adding libpg-dev (Ubuntu/Debian) along with other package
  managers to the list of dependencies to install before using pip:

  
http://docs.openstack.org/developer/keystone/devref/development.environment.html
  #installing-dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1608653/+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 1608332] Re: create pool api parameter issue

2016-08-01 Thread Victor Morales

** Also affects: openstack-api-site
   Importance: Undecided
   Status: New

** No longer affects: openstack-api-site

** Project changed: neutron => openstack-api-site

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

Title:
  create pool api parameter issue

Status in openstack-api-site:
  New

Bug description:
  There is a bug in the documentation[1] for lbaas v2 pool create
  parameters.  The request parameter mentioned are

  {
  "pool": {
  "admin_state_up": true,
  "description": "simple pool",
  "lb_algorithm": "ROUND_ROBIN",
  "name": "my-pool",
  "protocol": "HTTP",
  "subnet_id": "e301aed0-d9e7-498a-977c-1bbfaf14ed5d"
  }
  }

  The creation of pool requires a listener ID instead of Subnet Id.

  [1] http://developer.openstack.org/api-
  ref/networking/v2-ext/index.html?expanded=create-a-load-balancer-pool-
  detail#id355

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-api-site/+bug/1608332/+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 1608643] [NEW] Add 'vhdx' disk format.

Public bug reported:

https://review.openstack.org/347352
Dear bug triager. This bug was created since a commit was marked with DOCIMPACT.
Your project "openstack/glance" 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 fc0b47beb60c0dbbe620798665d0e9bab07f7029
Author: Stuart McLaren 
Date:   Tue Jul 26 12:29:37 2016 +

Add 'vhdx' disk format.

This patch adds the Hyper-V 'vhdx' disk format to the Glance
configuration. This allows users to upload 'vhdx' images by default.

'vhdx' disks can have much larger storage capacity than the older 'vhd'
format [1].  (Plus, anything with 'x' in the name is awesome.)

DocImpact: Docs will need to be updated to indicate that the 'vhdx'
disk_format is now one of the default disk formats supported by Glance.

UpgradeImpact: Adds 'vhdx' to the default list of disk_formats.  Operators
will no longer need to configure specifically to use 'vhdx' disks.

[1] https://technet.microsoft.com/en-us/library/hh831446(v=ws.11).aspx

Spec-Lite: https://review.openstack.org/#/c/347626
Change-Id: I4e172c78d7afeb8be5a0123238efe3d8e4b044c9

** Affects: glance
 Importance: Undecided
 Status: New


** Tags: doc glance

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

Title:
  Add 'vhdx' disk format.

Status in Glance:
  New

Bug description:
  https://review.openstack.org/347352
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/glance" 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 fc0b47beb60c0dbbe620798665d0e9bab07f7029
  Author: Stuart McLaren 
  Date:   Tue Jul 26 12:29:37 2016 +

  Add 'vhdx' disk format.
  
  This patch adds the Hyper-V 'vhdx' disk format to the Glance
  configuration. This allows users to upload 'vhdx' images by default.
  
  'vhdx' disks can have much larger storage capacity than the older 'vhd'
  format [1].  (Plus, anything with 'x' in the name is awesome.)
  
  DocImpact: Docs will need to be updated to indicate that the 'vhdx'
  disk_format is now one of the default disk formats supported by Glance.
  
  UpgradeImpact: Adds 'vhdx' to the default list of disk_formats.  Operators
  will no longer need to configure specifically to use 'vhdx' disks.
  
  [1] https://technet.microsoft.com/en-us/library/hh831446(v=ws.11).aspx
  
  Spec-Lite: https://review.openstack.org/#/c/347626
  Change-Id: I4e172c78d7afeb8be5a0123238efe3d8e4b044c9

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1608643/+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 1578866] Re: Race condition between token validation and revocation API causes intermittent gate failures.

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

** Changed in: keystone
Milestone: newton-3 => newton-1

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

Title:
  Race condition between token validation and revocation API causes
  intermittent gate failures.

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  test_user_update_own_password is failing intermittently on a variety
  of jobs

  stack trace:
  Traceback (most recent call last):
File "tempest/api/identity/v2/test_users.py", line 71, in 
test_user_update_own_password
  self.non_admin_users_client.token)
File 
"/opt/stack/new/tempest/.tox/tempest/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 480, in assertRaises
  self.assertThat(our_callable, matcher)
File 
"/opt/stack/new/tempest/.tox/tempest/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 493, in assertThat
  raise mismatch_error
  testtools.matchers._impl.MismatchError: > returned {u'token': {u'expires': u'2016-05-06T00:13:53Z', 
u'issued_at': u'2016-05-05T23:13:54.00Z', u'audit_ids': 
[u'mbdiQZcNT5GxEUebXZqKOA', u'BAlcCwKLS9Co8C3jg2vfAw'], u'id': 
u'gABXK9Oyhuw7yBJJehrIIGlzIB8VTbgnM_M5Cve9q0BEHeZ2xNohJ_lkVqp7kicVbNgZ93p2dcLHfUfXWCcPvO4BWkTIry1mAGSvhzeLI7SYxSS6CBpeGK0FH3Uf_5vhHTCWFvcDvKOSzajGImeN7GaYts91H1zsXV7B1HRs0xN-4LADokI'},
 u'metadata': {u'roles': [], u'is_admin': 0}, u'serviceCatalog': [], u'user': 
{u'roles_links': [], u'username': u'tempest-IdentityUsersTest-972219078', 
u'name': u'tempest-IdentityUsersTest-972219078', u'roles': [], u'id': 
u'97a1836c5a2c40c99575e46aa37b8b50'}}

  
  example failures: 
http://logs.openstack.org/17/311617/1/gate/gate-tempest-dsvm-neutron-linuxbridge/084f25d/logs/testr_results.html.gz

  and http://logs.openstack.org/91/312791/2/check/gate-tempest-dsvm-
  full/88d9fff/logs/testr_results.html.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1578866/+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 1603038] Re: Execption on admin_token usage ValueError: Unrecognized

** Changed in: keystonemiddleware
   Status: Triaged => Invalid

** Changed in: keystonemiddleware
   Importance: Medium => Undecided

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

Title:
  Execption on admin_token usage ValueError: Unrecognized

Status in OpenStack Identity (keystone):
  In Progress
Status in keystonemiddleware:
  Invalid

Bug description:
  1. iniset keystone.conf DEFAULT admin_token deprecated
  2. reload keystone (systemctl restart httpd)
  3. curl -g -i -X GET http://192.168.9.98/identity_v2_admin/v2.0/users -H 
"User-Agent: python-keystoneclient" -H "Accept: application/json" -H 
"X-Auth-Token: deprecated"


  I know the admin_token is deprecated, but is should be handled without
  throwing an extra exception.


  2016-07-14 11:00:28.487 20453 WARNING keystone.middleware.core 
[req-f13bf34e-4b80-4c2b-8e47-646ce5665abf - - - - -] The admin_token_auth 
middleware presents a security risk and should be removed from the 
[pipeline:api_v3], [pipeline:admin_api], and [pipeline:public_api] sections of 
your paste ini file.
  2016-07-14 11:00:28.593 20453 DEBUG keystone.middleware.auth 
[req-f13bf34e-4b80-4c2b-8e47-646ce5665abf - - - - -] Authenticating user token 
process_request 
/usr/lib/python2.7/site-packages/keystonemiddleware/auth_token/__init__.py:354
  2016-07-14 11:00:28.593 20453 WARNING keystone.middleware.auth 
[req-f13bf34e-4b80-4c2b-8e47-646ce5665abf - - - - -] Invalid token contents.
  2016-07-14 11:00:28.593 20453 TRACE keystone.middleware.auth Traceback (most 
recent call last):
  2016-07-14 11:00:28.593 20453 TRACE keystone.middleware.auth   File 
"/usr/lib/python2.7/site-packages/keystonemiddleware/auth_token/__init__.py", 
line 399, in _do_fetch_token
  2016-07-14 11:00:28.593 20453 TRACE keystone.middleware.auth return data, 
access.create(body=data, auth_token=token)
  2016-07-14 11:00:28.593 20453 TRACE keystone.middleware.auth   File 
"/usr/lib/python2.7/site-packages/positional/__init__.py", line 101, in inner
  2016-07-14 11:00:28.593 20453 TRACE keystone.middleware.auth return 
wrapped(*args, **kwargs)
  2016-07-14 11:00:28.593 20453 TRACE keystone.middleware.auth   File 
"/usr/lib/python2.7/site-packages/keystoneauth1/access/access.py", line 49, in 
create
  2016-07-14 11:00:28.593 20453 TRACE keystone.middleware.auth raise 
ValueError('Unrecognized auth response')
  2016-07-14 11:00:28.593 20453 TRACE keystone.middleware.auth ValueError: 
Unrecognized auth response
  2016-07-14 11:00:28.593 20453 TRACE keystone.middleware.auth 
  2016-07-14 11:00:28.594 20453 INFO keystone.middleware.auth 
[req-f13bf34e-4b80-4c2b-8e47-646ce5665abf - - - - -] Invalid user token
  2016-07-14 11:00:28.595 20453 DEBUG keystone.middleware.auth 
[req-d1c79cbf-698f-4844-9efd-7be444040cf0 - - - - -] RBAC: auth_context: {} 
fill_context /opt/stack/keystone/keystone/middleware/auth.py:219
  2016-07-14 11:00:28.604 20453 INFO keystone.common.wsgi 
[req-d1c79cbf-698f-4844-9efd-7be444040cf0 - - - - -] GET 
http://192.168.9.98/identity_v2_admin/v2.0/users
  2016-07-14 11:00:28.604 20453 WARNING oslo_log.versionutils 
[req-d1c79cbf-698f-4844-9efd-7be444040cf0 - - - - -] Deprecated: get_users of 
the v2 API is deprecated as of Mitaka in favor of a similar function in the v3 
API and may be removed in Q.
  2016-07-14 11:00:28.622 20453 DEBUG oslo_db.sqlalchemy.engines 
[req-d1c79cbf-698f-4844-9efd-7be444040cf0 - - - - -] MySQL server mode set to 
STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
 _check_effective_sql_mode 
/usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/engines.py:256

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1603038/+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 1608623] [NEW] Policy service caching does not work within hz-dynamic-table

2016-08-01 Thread Travis Tripp

Public bug reported:

The policy service caching (where it ensures that if you look up the
same policy more than once) does not seem to work under hz-dynamic-
table.

Turn on ng-images which recently migrated to hz-dynamic-table and watch
the network calls.  You'll note a bunch of policy calls and if you look
at the request body, you'll see the same rules going in multiple times.

http://imgur.com/a/Sh4fj

** Affects: horizon
 Importance: Undecided
 Assignee: Travis Tripp (travis-tripp)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => Travis Tripp (travis-tripp)

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

Title:
  Policy service caching does not work within hz-dynamic-table

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  The policy service caching (where it ensures that if you look up the
  same policy more than once) does not seem to work under hz-dynamic-
  table.

  Turn on ng-images which recently migrated to hz-dynamic-table and
  watch the network calls.  You'll note a bunch of policy calls and if
  you look at the request body, you'll see the same rules going in
  multiple times.

  http://imgur.com/a/Sh4fj

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1608623/+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 1608601] [NEW] create_port is failing for non admin context as Nova neutronclient interactions are not using admin context consistently

2016-08-01 Thread Esha Seth

Public bug reported:

There have been several changes in community in Newton on nova and
neutron client interactions. The interactions are not consistently using
admin context and credentials/token of nova user always instead
sometimes using the logged in user credentials. Due to this the
create_port is not getting allowed for non-admin users.

https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L117-L137

# NOTE(dprince): In the case where no auth_token is present we allow use
of # neutron admin tenant credentials if it is an admin context. This is
to # support some services (metadata API) where an admin context is used
# without an auth token

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

Title:
  create_port is failing for non admin context as Nova neutronclient
  interactions are not using admin context consistently

Status in OpenStack Compute (nova):
  New

Bug description:
  There have been several changes in community in Newton on nova and
  neutron client interactions. The interactions are not consistently
  using admin context and credentials/token of nova user always instead
  sometimes using the logged in user credentials. Due to this the
  create_port is not getting allowed for non-admin users.

  
https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L117-L137

  # NOTE(dprince): In the case where no auth_token is present we allow
  use of # neutron admin tenant credentials if it is an admin context.
  This is to # support some services (metadata API) where an admin
  context is used # without an auth token

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1608601/+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 1492773] Re: there are a lot of warn log "No DHCP agents available, skipping rescheduling""

2016-08-01 Thread John Joyce

** Changed in: neutron
 Assignee: (unassigned) => John Joyce (joycej)

** Changed in: neutron
   Status: Expired => 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/1492773

Title:
  there are a lot of warn  log "No DHCP agents available, skipping
  rescheduling""

Status in neutron:
  Confirmed

Bug description:
  when no agent is active,  there are a lot of warn  log "No DHCP agents 
available, skipping rescheduling",
  which are so many that it is difficult to read log

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1492773/+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 1608593] [NEW] Nova exception "DBDuplicateEntry" error in n-cond.log

2016-08-01 Thread Michael Johnson

Public bug reported:

I'm running current master nova under devstack on ubuntu 14.04

nova git log:
commit eab62c0d8a3280c559d974d0f31d51a3f06e1048
Merge: dd9af27 b790332
Author: Jenkins 
Date:   Mon Aug 1 00:24:20 2016 +

Merge "Option Consistency for availability_zone.py"

Steps to reproduce:
1. Boot up an instance with a network port.
2. Update the port with "device_id" blank.
3. Delete the nova instance.
4. Attempt to boot a new instance with the port.
5. Update the port with "device_id" blank.
6. Delete the nova instance.
7. Attempt to boot a new instance with the port.

This is a multi-failover scenario.

Error from n-cond.log:
/python2.7/dist-packages/sqlalchemy/orm/session.py", line 2137, in _flush
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api 
transaction.rollback(_capture_exception=True)
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py", line 
60, in __exit__
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api 
compat.reraise(exc_type, exc_value, exc_tb)
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 2101, 
in _flush
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api flush_context.execute()
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/unitofwork.py", line 
373, in execute
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api rec.execute(self)
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/unitofwork.py", line 
532, in execute
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api uow
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/persistence.py", line 
174, in save_obj
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api mapper, table, insert)
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/persistence.py", line 
800, in _emit_insert_statements
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api execute(statement, 
params)
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 914, 
in execute
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api return meth(self, 
multiparams, params)
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/sql/elements.py", line 323, 
in _execute_on_connection
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api return 
connection._execute_clauseelement(self, multiparams, params)
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1010, 
in _execute_clauseelement
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api compiled_sql, 
distilled_params
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1146, 
in _execute_context
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api context)
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1337, 
in _handle_dbapi_exception
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api 
util.raise_from_cause(newraise, exc_info)
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 202, 
in raise_from_cause
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api 
reraise(type(exception), exception, tb=exc_tb, cause=cause)
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1139, 
in _execute_context
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api context)
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 
450, in do_execute
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api 
cursor.execute(statement, parameters)
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/cursors.py", line 167, in 
execute
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api result = 
self._query(query)
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/cursors.py", line 323, in _query
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api conn.query(q)
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 836, in 
query
2016-08-01 15:44:12.981 TRACE nova.db.sqlalchemy.api

[Yahoo-eng-team] [Bug 1604471] Re: neutron-lib api-ref response code formatting

Reviewed:  https://review.openstack.org/345024
Committed: 
https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=980068fb05da7385c8e5f4096a48a89d0dfd64ba
Submitter: Jenkins
Branch:master

commit 980068fb05da7385c8e5f4096a48a89d0dfd64ba
Author: Boden R 
Date:   Wed Jul 20 14:07:48 2016 -0600

Fix api-ref response code formatting

Normalizes api-ref response code formatting so that
normal and error response codes are on their own line
and have a space before any lists of codes.

Change-Id: I740288f376d52eeaff7e28477c9b96dda997bce9
Closes-Bug: #1604471


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

Title:
  neutron-lib api-ref response code formatting

Status in neutron:
  Fix Released

Bug description:
  As per recent review comments on neutron-lib api-ref [1]:

  - There should be a space between Normal/Error response codes.
  - No trailing comma should exist for a list of codes.

  Today we have a number of places in the api-ref .inc files that do not
  conform; this defect is to track the clean-up of this formatting.

  
  [1] https://review.openstack.org/#/c/339643/1/api-ref/source/v2/networks.inc

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1604471/+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 1433331] Re: Collapse Fernet specific tests into test_v3_auth.py TestAuth

** Changed in: keystone
   Status: Fix Committed => Fix Released

** Changed in: keystone
 Assignee: (unassigned) => Lance Bragstad (lbragstad)

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

Title:
  Collapse Fernet specific tests into test_v3_auth.py TestAuth

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  When the Fernet token implementation landed, it was introduced with
  it's own testing layer [1]. These tests were designed to model the
  behavior specific to Fernet tokens. Fernet tokens should have the same
  V3 behavior as the rest of the token providers available in Keystone,
  which has been worked towards [2]. If the behavior is the same, then
  we should use the same tests with each provider. The
  TestFernetTokenProvider test cases should be analyzed and ported to
  TestAuth if not already there. Then we can leverage the work across
  all providers without having a bunch of tests that describe the same
  behavior for different providers.

  [1] 
https://github.com/openstack/keystone/blob/3910931b464c143b3be38c39e70038498860a8bd/keystone/tests/unit/test_v3_auth.py#L4053
  [2] https://review.openstack.org/#/c/164348/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/141/+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 1608565] [NEW] Horizon ignores instance snapshot as pre-selected source image

2016-08-01 Thread ebl...@nde.ag

Public bug reported:

Description of problem:
When launching an instance from an instance snapshot via Horizon images 
overview (Button "Launch") the resulting "Launch instance"-dialog ignores the 
selected image, the source has to be selected again. This only affects 
"Instance Snapshot" as source type, the other source types (Image, Volume, 
Volume Snapshot) are accepted.

Versions:
OpenStack Mitaka on openSUSE_Leap_42.1
openstack-dashboard-9.0.2~a0~dev22-1.1.noarch

How reproducible:
Every time

Steps to Reproduce:
1. Create a snapshot from a running instance.
2. From the images overview (http://control/project/images/) click on the new 
image (instance snapshot).

Actual result:
In the "Launch Instance"-dialog no image is selected in the "Source" tab and 
it's marked with an asterisk, an image has to be selected (again).

Expected result:
The form field in "Source" should be pre-allocated by the instance snapshot and 
"Source" should not be marked by an asterisk.

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

Title:
  Horizon ignores instance snapshot as pre-selected source image

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Description of problem:
  When launching an instance from an instance snapshot via Horizon images 
overview (Button "Launch") the resulting "Launch instance"-dialog ignores the 
selected image, the source has to be selected again. This only affects 
"Instance Snapshot" as source type, the other source types (Image, Volume, 
Volume Snapshot) are accepted.

  Versions:
  OpenStack Mitaka on openSUSE_Leap_42.1
  openstack-dashboard-9.0.2~a0~dev22-1.1.noarch

  How reproducible:
  Every time

  Steps to Reproduce:
  1. Create a snapshot from a running instance.
  2. From the images overview (http://control/project/images/) click on the new 
image (instance snapshot).

  Actual result:
  In the "Launch Instance"-dialog no image is selected in the "Source" tab and 
it's marked with an asterisk, an image has to be selected (again).

  Expected result:
  The form field in "Source" should be pre-allocated by the instance snapshot 
and "Source" should not be marked by an asterisk.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1608565/+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 1592713] Re: wrong url for list role identity v2 API

2016-08-01 Thread David Stanek

This was fixed in https://review.openstack.org/#/c/343130/

** Changed in: keystone
   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/1592713

Title:
  wrong url for list role identity v2 API

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  Keystone has list roles API but its url is wrong here-
  http://developer.openstack.org/api-ref-identity-v2-ext.html#listRoles

  It should be '/v2.0/OS-KSADM/roles'

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1592713/+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 1608553] [NEW] simplify chained comparison

2016-08-01 Thread liao...@hotmail.com

Public bug reported:

simplify chained comparison on
./openstack_dashboard/dashboards/identity/projects/workflows.py:104

** Affects: horizon
 Importance: Undecided
 Assignee: liao...@hotmail.com (liaozd)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => liao...@hotmail.com (liaozd)

** Description changed:

- simplify chained comparison
+ simplify chained comparison on
+ ./openstack_dashboard/dashboards/identity/projects/workflows.py:104

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

Title:
  simplify chained comparison

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  simplify chained comparison on
  ./openstack_dashboard/dashboards/identity/projects/workflows.py:104

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1608553/+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 1433331] Re: Collapse Fernet specific tests into test_v3_auth.py TestAuth

2016-08-01 Thread Lance Bragstad

I think this can be closed now since a bunch of fixes landed to make
fernet the default [0]. The TestFernetTokenProvider class has been
refactored in master and no longer exists. It has been replaced with
Fernet test classes that inherit tests from general test classes.

[0]
https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:make-fernet-default

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

** Changed in: keystone
Status: Won't Fix => Fix Committed

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

Title:
Collapse Fernet specific tests into test_v3_auth.py TestAuth

Status in OpenStack Identity (keystone):
Fix Committed

Bug description:
When the Fernet token implementation landed, it was introduced with
it's own testing layer [1]. These tests were designed to model the
behavior specific to Fernet tokens. Fernet tokens should have the same
V3 behavior as the rest of the token providers available in Keystone,
which has been worked towards [2]. If the behavior is the same, then
we should use the same tests with each provider. The
TestFernetTokenProvider test cases should be analyzed and ported to
TestAuth if not already there. Then we can leverage the work across
all providers without having a bunch of tests that describe the same
behavior for different providers.

[1]
https://github.com/openstack/keystone/blob/3910931b464c143b3be38c39e70038498860a8bd/keystone/tests/unit/test_v3_auth.py#L4053
[2] https://review.openstack.org/#/c/164348/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/141/+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 1549814] Re: Metadata caching is fundamentally broken

Caching models like this probably really should see a spec just to think
through the access patterns, especially as people keep proposing to make
MD writable from the guest, which impacts this.

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

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

Title:
  Metadata caching is fundamentally broken

Status in OpenStack Compute (nova):
  Opinion

Bug description:
  The caching backend for memcached/dogpile stores whole Python objects
  by creating a deep copy. Metadata is cached by storing the metadata
  Python object, and therefore the whole object tree underneath,
  including the "instance" attribute.  Whenever the metadata is fetched,
  it also fetches the old version of instance with it, and works on it.
  This has several implications, like for example lazy fetched fields of
  the "instance" object are never cached, if they are not pre-fetched
  before caching. Also it might implicate security issues.

  It would be probably a better approach to actually cache the DB query
  results only, and not the whole populated "living" object.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1549814/+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 1608532] [NEW] import should be alphabetically

2016-08-01 Thread liao...@hotmail.com

Public bug reported:

openstack_dashboard/dashboards/identity/projects/workflows.py is not
alphabetically imported

** Affects: horizon
 Importance: Undecided
 Assignee: liao...@hotmail.com (liaozd)
 Status: New


** Tags: pep8

** Changed in: horizon
 Assignee: (unassigned) => liao...@hotmail.com (liaozd)

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

Title:
  import should be alphabetically

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  openstack_dashboard/dashboards/identity/projects/workflows.py is not
  alphabetically imported

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1608532/+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 1595965] Re: transport_url is being parsed different when forking with oslo.service

this feels like it may very well be an issue in oslo.service itself,
adding that

** Also affects: oslo.service
   Importance: Undecided
   Status: New

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

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

Title:
  transport_url is being parsed different when forking with oslo.service

Status in OpenStack Compute (nova):
  Incomplete
Status in oslo.service:
  New

Bug description:
  This is a strange one. I had setup my transport_url incorrectly which
  made me discover this. I am filing this bug because I believe there is
  one.

  When using a correctly formatted transport_url that was missing data
  _and_ multiple workers for conductor it would incorrectly parse the
  transport_url.

  Here is the incorrect transport_url:

  rabbit://:@server01,server02/openstack

  The correct transport_url should be:

  rabbit://:@server01,:@server02/openstack

  According to the docs [1], when the username and password is not
  specified, the server should be omitted from the list of servers. So
  for the incorrect transport_url only server01 would be setup.  Here is
  a list of scenarios and what the behavior I see is.

  * with the incorrect transport_url and a single thread all services contact 
only server01
  * with the incorrect transport_url and multiple threads all services contact 
only server01 _except_ conductor which will attempt to contact server02 with 
the default username and password
  * with the correct transport_url all services contact server01 and server02 
properly

  To reproduce this, get two rabbitmq hosts and set the incorrect
  transport_url and at least 2 conductor workers. Look at the rabbitmq
  logs on server02 and youll see it is trying to login via the guest
  user. Set the number of workers to 1 and notice there is no bad logins
  in rabbitmq logs. Fix the transport_url and it will use all servers
  appropriately no matter the number of workers.

  The following is a gut feeling. I believe the issue is around the
  point it gets forked with oslo.service. It may not properly be
  reparsing the transport_url. I couldn't prove that though.

  Nova versions tested: 13.0.0 and 13.1.0
  all libraries were within the upper-constraints for mitaka

  [1] http://docs.openstack.org/developer/oslo.messaging/transport.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1595965/+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 1589221] Re: Nova-compute: "ImageNotFound: Image could not be found."

2016-08-01 Thread James Page

Dropping Nova task, this is not a Nova bug.

** Changed in: nova
   Status: Incomplete => Invalid

** Changed in: nova-compute (Juju Charms Collection)
   Status: New => Incomplete

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

Title:
  Nova-compute: "ImageNotFound: Image  could not be found."

Status in OpenStack Compute (nova):
  Invalid
Status in nova-compute package in Juju Charms Collection:
  Incomplete

Bug description:
  Spawning a new instance using a newly created image most of the time
  fails. After 2-3 attempts, the problem gets resolved.

  The configs that I'm using in my HA-environment are:
  nova-compute:
  enable-live-migration: "True"
  enable-resize: "True"
  openstack-origin: "cloud:trusty-mitaka"
  migration-auth-type: "ssh"
  manage-neutron-plugin-legacy-mode: False
  glance:
  openstack-origin: "cloud:trusty-mitaka"
  region: "serverstack"
  vip: 
  nova-cloud-controller:
  network-manager: "Neutron"
  console-access-protocol: "novnc"
  openstack-origin: "cloud:trusty-mitaka"
  region: "serverstack"
  vip: 

  I have one compute. Compute logs: http://paste.ubuntu.com/17026140/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1589221/+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 1598833] Re: Apparmor causes: libvirtError: operation failed: open disk image file failed during online snapshots via Nova API

I don't think this is really a nova issue, apparmor config is beyond the
project scope.

** Changed in: nova
   Status: New => Won't Fix

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

Title:
  Apparmor causes: libvirtError: operation failed: open disk image file
  failed during online snapshots via Nova API

Status in OpenStack Compute (nova):
  Won't Fix

Bug description:
  Quobyte CI fails test_snapshot_create_with_volume_in_use (v1 and v2)
  tests with "libvirtError: operation failed: open disk image file
  failed" . Nova compute log shows:

  2016-07-04 09:06:35.649 7297 DEBUG oslo_concurrency.processutils 
[req-84dbb010-c105-4b5b-8d1d-41028c114307 
tempest-VolumesV2SnapshotTestJSON-1508672341 
tempest-VolumesV2SnapshotTestJSON-1508672341] u'findmnt --t
  arget /mnt/quobyte-volume/abfa1002557ab2b21ec218a86487dd92 --source 
quobyte@78.46.57.153:7861/quobyteci_test_volume' failed. Not Retrying. execute 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processu
  tils.py:422
  2016-07-04 09:06:35.649 7297 DEBUG nova.virt.libvirt.volume.quobyte 
[req-84dbb010-c105-4b5b-8d1d-41028c114307 
tempest-VolumesV2SnapshotTestJSON-1508672341 
tempest-VolumesV2SnapshotTestJSON-1508672341] Mounting v
  olume 78.46.57.153:7861/quobyteci_test_volume at mount point 
/mnt/quobyte-volume/abfa1002557ab2b21ec218a86487dd92 ... mount_volume 
/opt/stack/nova/nova/virt/libvirt/volume/quobyte.py:53
  2016-07-04 09:06:35.649 7297 DEBUG oslo_concurrency.processutils 
[req-84dbb010-c105-4b5b-8d1d-41028c114307 
tempest-VolumesV2SnapshotTestJSON-1508672341 
tempest-VolumesV2SnapshotTestJSON-1508672341] Running cmd (
  subprocess): mount.quobyte 78.46.57.153:7861/quobyteci_test_volume 
/mnt/quobyte-volume/abfa1002557ab2b21ec218a86487dd92 execute 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:344
  2016-07-04 09:06:36.830 7297 DEBUG oslo_concurrency.processutils 
[req-84dbb010-c105-4b5b-8d1d-41028c114307 
tempest-VolumesV2SnapshotTestJSON-1508672341 
tempest-VolumesV2SnapshotTestJSON-1508672341] CMD "mount.qu
  obyte 78.46.57.153:7861/quobyteci_test_volume 
/mnt/quobyte-volume/abfa1002557ab2b21ec218a86487dd92" returned: 0 in 1.181s 
execute 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:374
  2016-07-04 09:06:36.832 7297 INFO nova.virt.libvirt.volume.quobyte 
[req-84dbb010-c105-4b5b-8d1d-41028c114307 
tempest-VolumesV2SnapshotTestJSON-1508672341 
tempest-VolumesV2SnapshotTestJSON-1508672341] Mounted vol
  ume: 78.46.57.153:7861/quobyteci_test_volume
  2016-07-04 09:06:36.832 7297 DEBUG oslo_concurrency.processutils 
[req-84dbb010-c105-4b5b-8d1d-41028c114307 
tempest-VolumesV2SnapshotTestJSON-1508672341 
tempest-VolumesV2SnapshotTestJSON-1508672341] Running cmd (
  subprocess): getfattr -n quobyte.info 
/mnt/quobyte-volume/abfa1002557ab2b21ec218a86487dd92 execute 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:344
  2016-07-04 09:06:36.853 7297 DEBUG oslo_concurrency.processutils 
[req-84dbb010-c105-4b5b-8d1d-41028c114307 
tempest-VolumesV2SnapshotTestJSON-1508672341 
tempest-VolumesV2SnapshotTestJSON-1508672341] CMD "getfattr
   -n quobyte.info /mnt/quobyte-volume/abfa1002557ab2b21ec218a86487dd92" 
returned: 0 in 0.021s execute 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:374
  2016-07-04 09:06:36.854 7297 DEBUG oslo_concurrency.lockutils 
[req-84dbb010-c105-4b5b-8d1d-41028c114307 
tempest-VolumesV2SnapshotTestJSON-1508672341 
tempest-VolumesV2SnapshotTestJSON-1508672341] Lock "connect_vo
  lume" released by "nova.virt.libvirt.volume.quobyte.connect_volume" :: held 
1.232s inner 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:282
  2016-07-04 09:06:36.857 7297 DEBUG nova.virt.libvirt.guest 
[req-84dbb010-c105-4b5b-8d1d-41028c114307 
tempest-VolumesV2SnapshotTestJSON-1508672341 
tempest-VolumesV2SnapshotTestJSON-1508672341] attach device xml: 
  



4604d6b5-cf47-4494-8833-15029e30a77e
  
   attach_device /opt/stack/nova/nova/virt/libvirt/guest.py:251  
  2016-07-04 09:06:38.512 7297 ERROR nova.virt.libvirt.driver 
[req-84dbb010-c105-4b5b-8d1d-41028c114307 
tempest-VolumesV2SnapshotTestJSON-1508672341 
tempest-VolumesV2SnapshotTestJSON-1508672341] [instance: 
0713aaa8-f630-4c7f-b541-616ce6541615] Failed to attach volume at mountpoint: 
/dev/vdb
  2016-07-04 09:06:38.512 7297 ERROR nova.virt.libvirt.driver [instance: 
0713aaa8-f630-4c7f-b541-616ce6541615] Traceback (most recent call last):
  2016-07-04 09:06:38.512 7297 ERROR nova.virt.libvirt.driver [instance: 
0713aaa8-f630-4c7f-b541-616ce6541615]   File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 1232, in attach_volume
  2016-07-04 09:06:38.512 7297 ERROR nova.virt.libvirt.driver [instance: 
0713aaa8-f630-4c7f-b541-616ce6541615] guest.attach_device(conf, 
persistent=True, live=live)

[Yahoo-eng-team] [Bug 1595864] Re: live_migration() takes exactly 7 arguments (6 given) if upgrade_levels compute=kilo

At this point, liberty is nearing EOL. So it's not really clear this is
going to be a thing we address.

** Changed in: nova
   Status: New => Won't Fix

** Changed in: nova
   Status: Won't Fix => Incomplete

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

Title:
  live_migration() takes exactly 7 arguments (6 given) if upgrade_levels
  compute=kilo

Status in OpenStack Compute (nova):
  Incomplete

Bug description:
  I have Liberty controller (nova-api, etc.) with

  [upgrade_levels]
  compute=kilo

  and Liberty compute node, when i try live-migration
  i see "live_migration() takes exactly 7 arguments (6 given)"
  in nova-compute.log.

  I can not completely remove compatibility with kilo,
  because i have kilo computes in my env.

  I also tried to add "upgrade_levels" to compute node,
  but with no luck.

  Environment
  ==
  Libvirt+KVM, Ceph for VMs
  Liberty - Mirantis OpenStack 8.0 (2015.2)

  Steps to reproduce
  ===
  1) Install Liberty control plane (api, conductor, schduler, etc.)
  2) Install Liberty computes
  3) Add to nova.conf on controller
[upgrade_levels]
compute=kilo
  3) Try "nova live-migration VM"

  Expected result
  =
  Migration will succeed

  Actual result
  ==
  Traceback on compute node
  http://paste.openstack.org/show/521871/

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

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

[Yahoo-eng-team] [Bug 1600109] Re: Unit tests should not perform logging, but some tests still use

2016-08-01 Thread Markus Zoeller (markus_z)

Nova has no rules in place which forbids that, so it's not a bug. I also
don't see a reason to put effort into this.

** Changed in: python-novaclient
   Status: Incomplete => Invalid

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

Title:
  Unit tests should not perform logging,but some tests still use

Status in Ceilometer:
  Incomplete
Status in Cinder:
  Incomplete
Status in Glance:
  Incomplete
Status in OpenStack Identity (keystone):
  Won't Fix
Status in Magnum:
  Incomplete
Status in OpenStack Compute (nova):
  Invalid
Status in python-cinderclient:
  Incomplete
Status in python-glanceclient:
  Incomplete
Status in python-keystoneclient:
  Won't Fix
Status in python-neutronclient:
  Incomplete
Status in python-novaclient:
  Invalid
Status in python-rackclient:
  Incomplete
Status in python-swiftclient:
  Incomplete
Status in rack:
  Incomplete
Status in OpenStack Object Storage (swift):
  Incomplete
Status in OpenStack DBaaS (Trove):
  Incomplete

Bug description:
  We shuld remove the logging

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

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

[Yahoo-eng-team] [Bug 1600109] Re: Unit tests should not perform logging, but some tests still use

2016-08-01 Thread Markus Zoeller (markus_z)

Nova has no rules in place which forbids that, so it's not a bug. I also
don't see a reason to put effort into this.

** Changed in: nova
   Status: Incomplete => Invalid

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

Title:
  Unit tests should not perform logging,but some tests still use

Status in Ceilometer:
  Incomplete
Status in Cinder:
  Incomplete
Status in Glance:
  Incomplete
Status in OpenStack Identity (keystone):
  Won't Fix
Status in Magnum:
  Incomplete
Status in OpenStack Compute (nova):
  Invalid
Status in python-cinderclient:
  Incomplete
Status in python-glanceclient:
  Incomplete
Status in python-keystoneclient:
  Won't Fix
Status in python-neutronclient:
  Incomplete
Status in python-novaclient:
  Invalid
Status in python-rackclient:
  Incomplete
Status in python-swiftclient:
  Incomplete
Status in rack:
  Incomplete
Status in OpenStack Object Storage (swift):
  Incomplete
Status in OpenStack DBaaS (Trove):
  Incomplete

Bug description:
  We shuld remove the logging

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

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

[Yahoo-eng-team] [Bug 1608467] Re: Hypervisor show not includes ram_allocation_ratio

This would be an API bump to add another field there, which means a
nova-spec.

Also, given that this is an admistrative API element, which was set by
configuration, it's not really clear that it's needed. A very specific
use case will need to be layed out for this.

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

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

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

Title:
  Hypervisor show not includes ram_allocation_ratio

Status in OpenStack Compute (nova):
  Opinion

Bug description:
  Description
  ===
  Now the nova hypervisor-show does not contain ram_allocation_ratio,
  cpu_allocation_ratio and disk_allocation_ratio.

  I think this is unreasonable，the user sets the allocation ratio 
  by using the configuration, but they can not see through hypervisor-show.

  Now nova hypervisor-show contains the following fileds:
- cpu_info: cpu_info
- state: hypervisor_state
- status: hypervisor_status
- current_workload: current_workload
- disk_available_least: disk_available_least
- host_ip: host_ip
- free_disk_gb: hypervisor_free_disk_gb
- free_ram_mb: free_ram_mb
- hypervisor_hostname: hypervisor_hostname
- hypervisor_type: hypervisor_type_body
- hypervisor_version: hypervisor_version
- id: hypervisor_id_body
- local_gb: local_gb
- local_gb_used: local_gb_used
- memory_mb: memory_mb
- memory_mb_used: memory_mb_used
- running_vms: running_vms
- service: hypervisor_service
- service.host: host_name_body
- service.id: service_id_body
- service.disable_reason: service_disable_reason
- vcpus: hypervisor_vcpus
- vcpus_used: hypervisor_vcpus_used

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1608467/+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 1607934] Re: Unable to launch an instance Bug 1219890

2016-08-01 Thread Markus Zoeller (markus_z)

That's a configuration issue and not a bug in the nova code base. You
can give this a try:
https://bugs.launchpad.net/nova/+bug/1534273/comments/8

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

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

Title:
  Unable to launch an instance Bug 1219890

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  I am unable to launch an instance.


  [root@controller keystone]# nova boot --flavor m1.tiny --image cirros
  --nic net-id=544bcd85-b051-4e42-a462-d7dab712de5a   --security-group
  default --key-name mykey public-instance

  # ERRORs I am seeing:
  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-5830ff32-d3e1-43a1-a3f9-7c6f96fb360b)

  ==> keystone/keystone.log <==
  2016-07-29 22:03:07.865 2175 INFO keystone.common.wsgi 
[req-7e612649-5070-49f7-87da-71afe5f1c51c - - - - -] GET 
http://controller:5000/v3/
  2016-07-29 22:03:07.980 2177 INFO keystone.common.wsgi 
[req-a6eda653-c25a-4453-b2e5-9736450f7568 - - - - -] POST 
http://controller:5000/v3/auth/tokens
  2016-07-29 22:03:08.034 2198 INFO keystone.common.wsgi 
[req-4f9430cd-7579-489e-9bc7-c5cb3f477d5a - - - - -] GET 
http://controller:35357/v3/auth/tokens
  2016-07-29 22:03:37.773 2186 INFO keystone.common.wsgi 
[req-8964cb8d-ea9c-4e7e-b153-4146c4e5b031 - - - - -] GET 
http://controller:5000/v3/
  2016-07-29 22:03:37.778 2176 INFO keystone.common.wsgi 
[req-31e52a1e-ac13-42d9-92c5-9deea759e9e9 - - - - -] POST 
http://controller:5000/v3/auth/tokens
  2016-07-29 22:03:37.828 2194 INFO keystone.common.wsgi 
[req-336a2901-5827-4508-829f-9de92ebd28da - - - - -] GET 
http://controller:35357/v3/auth/tokens
  2016-07-29 22:03:37.961 2203 INFO keystone.common.wsgi 
[req-eb3d31c9-0aa3-4572-b78a-e087ae509de9 - - - - -] GET 
http://controller:35357/v3/auth/tokens
  2016-07-29 22:03:37.985 2200 INFO keystone.common.wsgi 
[req-ef7ab927-e5b3-45c0-89f9-d7191dc4cea4 - - - - -] GET 
http://controller:35357/v3/auth/tokens
  2016-07-29 22:03:38.120 2197 INFO keystone.common.wsgi 
[req-1ceee11a-cc13-490a-96ba-47081c1fe154 - - - - -] GET 
http://controller:35357/v3/auth/tokens
  2016-07-29 22:03:38.174 2178 INFO keystone.common.wsgi 
[req-ebe3d994-18c2-4304-91a8-04143ba6a627 - - - - -] POST 
http://localhost:5000/v2.0/tokens
  2016-07-29 22:03:38.174 2178 WARNING keystone.common.wsgi 
[req-ebe3d994-18c2-4304-91a8-04143ba6a627 - - - - -] Expecting to find username 
or userId in passwordCredentials - the server could not comply with the request 
since it is either malformed or otherwise incorrect. The client is assumed to 
be in error.

  ==> nova/nova-scheduler.log <==
  [root@controller nova]# tail -1 nova-scheduler.log 
  2016-07-29 22:06:01.868 1409 INFO nova.scheduler.host_manager 
[req-1360cc28-fd91-42cb-918b-37db9432cc77 - - - - -] Successfully synced 
instances from host 'compute.example.com'.

  ==> nova/nova-api.log <==
  2016-07-29 22:05:12.728 8504 INFO nova.osapi_compute.wsgi.server 
[req-54a6644f-96fe-4663-9825-ebc0e1ac920b 5d7190fb0b224c3484be7854426c88b1 
7f659e1816d24cb2b2fdacfef970cfc6 - - -] 10.0.0.11 "GET /v2/ HTTP/1.1" status: 
200 len: 572 time: 0.0156450
  2016-07-29 22:05:12.898 8504 INFO nova.osapi_compute.wsgi.server 
[req-d1ad4413-4c34-4a58-8b30-8dd258a8c9b1 5d7190fb0b224c3484be7854426c88b1 
7f659e1816d24cb2b2fdacfef970cfc6 - - -] 10.0.0.11 "GET 
/v2/7f659e1816d24cb2b2fdacfef970cfc6/images HTTP/1.1" status: 200 len: 692 
time: 0.0624750
  2016-07-29 22:05:12.964 8504 INFO nova.osapi_compute.wsgi.server 
[req-d62a91fe-c059-46e9-9084-e6294c714d5c 5d7190fb0b224c3484be7854426c88b1 
7f659e1816d24cb2b2fdacfef970cfc6 - - -] 10.0.0.11 "GET 
/v2/7f659e1816d24cb2b2fdacfef970cfc6/images/ffc86274-9a08-4b13-a23d-37c49bedb818
 HTTP/1.1" status: 200 len: 873 time: 0.0643079
  2016-07-29 22:05:12.979 8504 INFO nova.api.openstack.wsgi 
[req-e6f20077-6da7-4423-bb04-791b8eb1db2c 5d7190fb0b224c3484be7854426c88b1 
7f659e1816d24cb2b2fdacfef970cfc6 - - -] HTTP exception thrown: Flavor m1.tiny 
could not be found.
  2016-07-29 22:05:12.980 8504 INFO nova.osapi_compute.wsgi.server 
[req-e6f20077-6da7-4423-bb04-791b8eb1db2c 5d7190fb0b224c3484be7854426c88b1 
7f659e1816d24cb2b2fdacfef970cfc6 - - -] 10.0.0.11 "GET 
/v2/7f659e1816d24cb2b2fdacfef970cfc6/flavors/m1.tiny HTTP/1.1" status: 404 len: 
298 time: 0.0130160
  2016-07-29 22:05:12.997 8504 INFO nova.osapi_compute.wsgi.server 
[req-c7db45cc-4338-4903-b97b-4672b96ac337 5d7190fb0b224c3484be7854426c88b1 
7f659e1816d24cb2b2fdacfef970cfc6 - - -] 10.0.0.11 "GET 
/v2/7f659e1816d24cb2b2fdacfef970cfc6/flavors?is_public=None HTTP/1.1" status: 
200 len: 1407 time: 0.0142021
  2016-07-29 22:05:13.012 8504 INFO nova.osapi_compute.wsgi.server 
[req-d82760c1-a126-4bbc-b599-5fa2a7d06bea 5d7190fb0b224c3484be7854426c88b1

[Yahoo-eng-team] [Bug 1608475] [NEW] Live Migration Error on Mitaka release

2016-08-01 Thread Vijay

Public bug reported:

While Live Migrating from one compute node to another compute node in
Mitaka release, the operation returns SUCCESS but the host system
remains same.

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

Title:
  Live Migration Error on Mitaka release

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  While Live Migrating from one compute node to another compute node in
  Mitaka release, the operation returns SUCCESS but the host system
  remains same.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1608475/+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 1608467] [NEW] Hypervisor show not includes ram_allocation_ratio

2016-08-01 Thread Tina Kevin

Public bug reported:

Description
===
Now the nova hypervisor-show does not contain ram_allocation_ratio,
cpu_allocation_ratio and disk_allocation_ratio.

I think this is unreasonable，the user sets the allocation ratio 
by using the configuration, but they can not see through hypervisor-show.

Now nova hypervisor-show contains the following fileds:
  - cpu_info: cpu_info
  - state: hypervisor_state
  - status: hypervisor_status
  - current_workload: current_workload
  - disk_available_least: disk_available_least
  - host_ip: host_ip
  - free_disk_gb: hypervisor_free_disk_gb
  - free_ram_mb: free_ram_mb
  - hypervisor_hostname: hypervisor_hostname
  - hypervisor_type: hypervisor_type_body
  - hypervisor_version: hypervisor_version
  - id: hypervisor_id_body
  - local_gb: local_gb
  - local_gb_used: local_gb_used
  - memory_mb: memory_mb
  - memory_mb_used: memory_mb_used
  - running_vms: running_vms
  - service: hypervisor_service
  - service.host: host_name_body
  - service.id: service_id_body
  - service.disable_reason: service_disable_reason
  - vcpus: hypervisor_vcpus
  - vcpus_used: hypervisor_vcpus_used

** Affects: nova
 Importance: Undecided
 Assignee: Tina Kevin (song-ruixia)
 Status: New


** Tags: allocation hypervisor-show ratio

** Tags added: allocation hypervisor-show ratio

** Changed in: nova
 Assignee: (unassigned) => Tina Kevin (song-ruixia)

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

Title:
  Hypervisor show not includes ram_allocation_ratio

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===
  Now the nova hypervisor-show does not contain ram_allocation_ratio,
  cpu_allocation_ratio and disk_allocation_ratio.

  I think this is unreasonable，the user sets the allocation ratio 
  by using the configuration, but they can not see through hypervisor-show.

  Now nova hypervisor-show contains the following fileds:
- cpu_info: cpu_info
- state: hypervisor_state
- status: hypervisor_status
- current_workload: current_workload
- disk_available_least: disk_available_least
- host_ip: host_ip
- free_disk_gb: hypervisor_free_disk_gb
- free_ram_mb: free_ram_mb
- hypervisor_hostname: hypervisor_hostname
- hypervisor_type: hypervisor_type_body
- hypervisor_version: hypervisor_version
- id: hypervisor_id_body
- local_gb: local_gb
- local_gb_used: local_gb_used
- memory_mb: memory_mb
- memory_mb_used: memory_mb_used
- running_vms: running_vms
- service: hypervisor_service
- service.host: host_name_body
- service.id: service_id_body
- service.disable_reason: service_disable_reason
- vcpus: hypervisor_vcpus
- vcpus_used: hypervisor_vcpus_used

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1608467/+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 1608462] [NEW] 'non-assignable' JS error in NG LI

2016-08-01 Thread Rob Cresswell

Public bug reported:

Seeing the following error in the new Launch Instance wizard in master:

angular.js:12783 Error: [$compile:nonassign] Expression '$isAvailableTable ? 
ctrl.availableTableConfig : ctrl.allocatedTableConfig' in attribute 'config' 
used with directive 'hzDynamicTable' is non-assignable!
http://errors.angularjs.org/1.4.10/$compile/nonassign?p0=%24isAvailableTabl…eTableConfig%20%3A%20ctrl.allocatedTableConfig=config=hzDynamicTable
at angular.js:68
at parentSet (angular.js:9137)
at parentValueWatch (angular.js:9150)
at regularInterceptedExpression (angular.js:14752)
at Scope.$digest (angular.js:16194)
at Scope.$apply (angular.js:16467)
at HTMLAnchorElement. (angular.js:24076)
at HTMLAnchorElement.dispatch (jquery.js:5095)
at HTMLAnchorElement.elemData.handle (jquery.js:4766)

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: angularjs

** Tags added: angularjs

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

Title:
  'non-assignable' JS error in NG LI

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Seeing the following error in the new Launch Instance wizard in
  master:

  angular.js:12783 Error: [$compile:nonassign] Expression '$isAvailableTable ? 
ctrl.availableTableConfig : ctrl.allocatedTableConfig' in attribute 'config' 
used with directive 'hzDynamicTable' is non-assignable!
  
http://errors.angularjs.org/1.4.10/$compile/nonassign?p0=%24isAvailableTabl…eTableConfig%20%3A%20ctrl.allocatedTableConfig=config=hzDynamicTable
  at angular.js:68
  at parentSet (angular.js:9137)
  at parentValueWatch (angular.js:9150)
  at regularInterceptedExpression (angular.js:14752)
  at Scope.$digest (angular.js:16194)
  at Scope.$apply (angular.js:16467)
  at HTMLAnchorElement. (angular.js:24076)
  at HTMLAnchorElement.dispatch (jquery.js:5095)
  at HTMLAnchorElement.elemData.handle (jquery.js:4766)

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1608462/+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 1608406] [NEW] BGP: DVR fip host routes query including legacy/HA fip routs

2016-08-01 Thread LIU Yulong

Public bug reported:

ENV:
neutron-8.1.2-1 (stable/mitaka)


When query a bgpspeaker's routes, the DVR fip host routes query will get the 
routes including the central fip routes.
This will let the central fip has more than one next_hop routes.

For instance:
+-+--+
| destination | next_hop |
+-+--+
| 172.16.10.69/32 | 172.16.10.57 | (ha)
| 172.16.10.69/32 | 172.16.10.65 | (ha)
| 172.16.10.70/32 | 172.16.10.58 | (legacy)
| 172.16.10.70/32 | 172.16.10.66 | (legacy)
| 172.16.10.68/32 | 172.16.10.66 | (dvr)
| 172.16.10.67/32 | 172.16.10.65 | (ha-and-dvr)
+-+--+

public (external) network ports:
172.16.10.69 network:floatingip
172.16.10.70 network:floatingip
172.16.10.68 network:floatingip
172.16.10.67 network:floatingip
172.16.10.66 network:floatingip_agent_gateway
172.16.10.65 network:floatingip_agent_gateway
172.16.10.59 network:router_gateway
172.16.10.57 network:router_gateway
172.16.10.58 network:router_gateway
172.16.10.60 network:router_gateway

This issue was tested in stable/mitaka, bug the upstream may also have the same 
issue.
Because this line did not filter the legacy/HA fips' routes:
https://github.com/openstack/neutron-dynamic-routing/blob/master/neutron_dynamic_routing/db/bgp_db.py#L732

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: l3-bgp

** Tags added: l3-bgp

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

Title:
  BGP: DVR fip host routes query including legacy/HA fip routs

Status in neutron:
  New

Bug description:
  ENV:
  neutron-8.1.2-1 (stable/mitaka)

  
  When query a bgpspeaker's routes, the DVR fip host routes query will get the 
routes including the central fip routes.
  This will let the central fip has more than one next_hop routes.

  For instance:
  +-+--+
  | destination | next_hop |
  +-+--+
  | 172.16.10.69/32 | 172.16.10.57 | (ha)
  | 172.16.10.69/32 | 172.16.10.65 | (ha)
  | 172.16.10.70/32 | 172.16.10.58 | (legacy)
  | 172.16.10.70/32 | 172.16.10.66 | (legacy)
  | 172.16.10.68/32 | 172.16.10.66 | (dvr)
  | 172.16.10.67/32 | 172.16.10.65 | (ha-and-dvr)
  +-+--+

  public (external) network ports:
  172.16.10.69 network:floatingip
  172.16.10.70 network:floatingip
  172.16.10.68 network:floatingip
  172.16.10.67 network:floatingip
  172.16.10.66 network:floatingip_agent_gateway
  172.16.10.65 network:floatingip_agent_gateway
  172.16.10.59 network:router_gateway
  172.16.10.57 network:router_gateway
  172.16.10.58 network:router_gateway
  172.16.10.60 network:router_gateway

  This issue was tested in stable/mitaka, bug the upstream may also have the 
same issue.
  Because this line did not filter the legacy/HA fips' routes:
  
https://github.com/openstack/neutron-dynamic-routing/blob/master/neutron_dynamic_routing/db/bgp_db.py#L732

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

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

[Yahoo-eng-team] [Bug 1600109] Re: Unit tests should not perform logging, but some tests still use

2016-08-01 Thread yuyafei

** Changed in: os-brick
 Assignee: yuyafei (yu-yafei) => (unassigned)

** No longer affects: os-brick

** No longer affects: python-heatclient

** No longer affects: neutron

** No longer affects: rally

** No longer affects: glance-store

** No longer affects: tempest

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

Title:
  Unit tests should not perform logging,but some tests still use

Status in Ceilometer:
  Incomplete
Status in Cinder:
  Incomplete
Status in Glance:
  Incomplete
Status in OpenStack Identity (keystone):
  Won't Fix
Status in Magnum:
  Incomplete
Status in OpenStack Compute (nova):
  Incomplete
Status in python-cinderclient:
  Incomplete
Status in python-glanceclient:
  Incomplete
Status in python-keystoneclient:
  Won't Fix
Status in python-neutronclient:
  Incomplete
Status in python-novaclient:
  Incomplete
Status in python-rackclient:
  Incomplete
Status in python-swiftclient:
  Incomplete
Status in rack:
  Incomplete
Status in OpenStack Object Storage (swift):
  Incomplete
Status in OpenStack DBaaS (Trove):
  Incomplete

Bug description:
  We shuld remove the logging

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

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

[Yahoo-eng-team] [Bug 1608400] [NEW] Neutron should not add ARP entry for allowed-address-pair-fixed-ip in DVR router

2016-08-01 Thread Heqing

Public bug reported:

When we set a fixed IP as allowed-address-pair IP, Neutron will notify
l3-agent to add permanent ARP entry for this IP in DVR router namespace.
But if we set the same IP to multiple ports as allowed-address-pair IP,
ARP entry with same IP but different MAC will be added multiple times.In
the end, the ARP entry will always lead us to last port that set the
fixed IP as allowed-address-pair.This makes VRRP application goes wrong.

This was noticed when deploying Octavia on Active/Standby mode.

How to reproduce:
1.Launch 2 VMs,vm-1 and vm-2, which connected to a DVR router.
2.Create an allowed-address-pair port
 Neutron port-create --name demo-port demo-net

3.Set allowed-address-pair for vm-1 and vm-2, use fixed IP of demo-port
 neutron port-update --allowed-address-pair ip_address=10.0.0.29 
3c8fac1c-4b1b-4258-8b18-8d74eebb48e4
 neutron port-update --allowed-address-pair ip_address=10.0.0.29 
a8b36d75-89ff-41d6-b891-fb65b7be88b4

4.Check ARP table of the DVR router.The ARP entry will always lead to 
10.0.0.21(vm-1).
[root@R1Network1 ~]# ip netns exec qrouter-4832ea04-cfa1-4c43-9ca9-e916b5fd1c28 
arp -n
Address  HWtype  HWaddress   Flags MaskIface
10.0.0.2 ether   fa:16:3e:78:91:99   CM
qr-2451ce9e-fa
10.0.0.21ether   fa:16:3e:a7:7d:7a   CM
qr-2451ce9e-fa *
10.0.0.29ether   fa:16:3e:a7:7d:7a   CM
qr-2451ce9e-fa *
10.0.0.20ether   fa:16:3e:16:da:45   CM
qr-2451ce9e-fa *
10.0.0.3 ether   fa:16:3e:bc:92:e9   CM
qr-2451ce9e-fa

** Affects: neutron
 Importance: Undecided
 Assignee: Heqing (tsinghe-7)
 Status: New


** Tags: allowed-address-pair dvr

** Changed in: neutron
 Assignee: (unassigned) => Heqing (tsinghe-7)

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

Title:
  Neutron should not add ARP entry for allowed-address-pair-fixed-ip in
  DVR  router

Status in neutron:
  New

Bug description:
  When we set a fixed IP as allowed-address-pair IP, Neutron will notify
  l3-agent to add permanent ARP entry for this IP in DVR router
  namespace. But if we set the same IP to multiple ports as allowed-
  address-pair IP, ARP entry with same IP but different MAC will be
  added multiple times.In the end, the ARP entry will always lead us to
  last port that set the fixed IP as allowed-address-pair.This makes
  VRRP application goes wrong.

  This was noticed when deploying Octavia on Active/Standby mode.

  How to reproduce:
  1.Launch 2 VMs,vm-1 and vm-2, which connected to a DVR router.
  2.Create an allowed-address-pair port
   Neutron port-create --name demo-port demo-net

  3.Set allowed-address-pair for vm-1 and vm-2, use fixed IP of demo-port
   neutron port-update --allowed-address-pair ip_address=10.0.0.29 
3c8fac1c-4b1b-4258-8b18-8d74eebb48e4
   neutron port-update --allowed-address-pair ip_address=10.0.0.29 
a8b36d75-89ff-41d6-b891-fb65b7be88b4

  4.Check ARP table of the DVR router.The ARP entry will always lead to 
10.0.0.21(vm-1).
  [root@R1Network1 ~]# ip netns exec 
qrouter-4832ea04-cfa1-4c43-9ca9-e916b5fd1c28 arp -n
  Address  HWtype  HWaddress   Flags Mask
Iface
  10.0.0.2 ether   fa:16:3e:78:91:99   CM
qr-2451ce9e-fa
  10.0.0.21ether   fa:16:3e:a7:7d:7a   CM
qr-2451ce9e-fa *
  10.0.0.29ether   fa:16:3e:a7:7d:7a   CM
qr-2451ce9e-fa *
  10.0.0.20ether   fa:16:3e:16:da:45   CM
qr-2451ce9e-fa *
  10.0.0.3 ether   fa:16:3e:bc:92:e9   CM
qr-2451ce9e-fa

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1608400/+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 1608402] [NEW] Volume size when using BDD driver

2016-08-01 Thread kryss

Public bug reported:

When using direct block device driver for Cinder the whole disk drive
space is used, so the setting of "Size (GiB)" have no effect, and should
be grayed when this type of driver is in use.

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

Title:
  Volume size when using BDD driver

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  When using direct block device driver for Cinder the whole disk drive
  space is used, so the setting of "Size (GiB)" have no effect, and
  should be grayed when this type of driver is in use.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1608402/+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 1606988] Re: saving metadata of array type error