[Yahoo-eng-team] [Bug 1820938] [NEW] typo of Horizon Dashboard UI

2019-03-19 Thread Takashi Kuroda
Public bug reported:

Release: OSP 15 Stein

File:
openstack_dashboard/dashboards/project/static/dashboard/project/workflow
/launch-instance/launch-instance-model.service.js:335

String:
Scheduled of %s instance.
 
Scheduled of %s instances.

Comment:
"creation" may be missing after each "Scheduled".
Please confirm.

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: i18n

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

Title:
  typo of Horizon Dashboard UI

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Release: OSP 15 Stein

  File:
  openstack_dashboard/dashboards/project/static/dashboard/project/workflow
  /launch-instance/launch-instance-model.service.js:335

  String:
  Scheduled of %s instance.
   
  Scheduled of %s instances.

  Comment:
  "creation" may be missing after each "Scheduled".
  Please confirm.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1820938/+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 1820935] [NEW] typo of Horizon Dashboard UI

2019-03-19 Thread Takashi Kuroda
Public bug reported:

Release: OSP 15 Stein

File:
openstack_dashboard/dashboards/admin/group_types/templates/group_types/_create_group_type.html:14

String:
Group type is a type or label that can be selected at group creation time in 
OpenStack. It usually maps to a set of capabilities of the storage back-end 
driver to be used for this volume. 

Comment:
Last "volume" may be "group".
Please confirm.

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: i18n

** Tags added: i18n

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

Title:
  typo of Horizon Dashboard UI

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Release: OSP 15 Stein

  File:
  
openstack_dashboard/dashboards/admin/group_types/templates/group_types/_create_group_type.html:14

  String:
  Group type is a type or label that can be selected at group creation time in 
OpenStack. It usually maps to a set of capabilities of the storage back-end 
driver to be used for this volume. 

  Comment:
  Last "volume" may be "group".
  Please confirm.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1820935/+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 1798184] Re: [SRU] PY3: python3-ldap does not allow bytes for DN/RDN/field names

2019-03-19 Thread Corey Bryant
** Changed in: cloud-archive
   Status: Fix Released => Fix Committed

** Changed in: cloud-archive/rocky
   Status: Triaged => 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/1798184

Title:
  [SRU] PY3: python3-ldap does not allow bytes for DN/RDN/field names

Status in Ubuntu Cloud Archive:
  Fix Committed
Status in Ubuntu Cloud Archive rocky series:
  Fix Committed
Status in Ubuntu Cloud Archive stein series:
  Fix Committed
Status in OpenStack Identity (keystone):
  Fix Released
Status in ldappool:
  Fix Released
Status in keystone package in Ubuntu:
  Fix Released
Status in python-ldappool package in Ubuntu:
  Fix Released
Status in keystone source package in Cosmic:
  Fix Committed
Status in python-ldappool source package in Cosmic:
  Fix Committed
Status in keystone source package in Disco:
  Fix Released
Status in python-ldappool source package in Disco:
  Fix Released

Bug description:
  [Impact]
  Keystone LDAP backend doesn't work for PY3.

  Under Python 2, python-ldap uses bytes by default. Under Python 3 this
  is removed and bytes aren't allowed for DN/RDN/field names.

  More details are here: 
http://www.python-ldap.org/en/latest/bytes_mode.html#bytes-mode
  and here: 
https://github.com/python-ldap/python-ldap/blob/python-ldap-3.1.0/Lib/ldap/ldapobject.py#L111

  == initial traceback ==

  Here's the initial traceback from the failure:
  https://paste.ubuntu.com/p/67THZb2m5m/

  The last bit of the error is:

    File "/usr/lib/python3/dist-packages/ldap/ldapobject.py", line 314, in 
_ldap_call
  result = func(*args,**kwargs)
  TypeError: simple_bind() argument 1 must be str or None, not bytes

  A closer look at func shows:

  func=
  args=(b'cn=admin,dc=test,dc=com', b'crapper', None, None)

  == keystone ldap backend use of python-ldap ==

  In simple_bind_s() of keystone's ldap backend, who and cred are
  encoded as byte strings:

  
https://github.com/openstack/keystone/blob/14.0.0/keystone/identity/backends/ldap/common.py#L885

  but that appears to no longer be valid use of python-ldap for py3.

  
  [Test Case]

  Run charm-keystone-ldap functional tests for OpenStack Rocky or above.

  [Regression Potential]
  The only regression potential would be for PY2 code paths. PY3 code paths 
never worked for keystone's LDAP backend. The approach to the patch have 
purposefully minimized amount of code required and therefore regression 
potential for PY2. Note that Rocky for Ubuntu supports PY2 but as of Stein 
Ubuntu has dropped PY2 support.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1798184/+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 1820333] Re: [SRU] ldap search should not encode attributes

2019-03-19 Thread Corey Bryant
** Also affects: keystone (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Changed in: keystone (Ubuntu Cosmic)
   Status: New => Triaged

** Changed in: keystone (Ubuntu Cosmic)
   Importance: Undecided => Critical

** Also affects: cloud-archive/rocky
   Importance: Undecided
   Status: New

** Changed in: cloud-archive/rocky
   Status: New => Triaged

** Changed in: cloud-archive/rocky
   Importance: Undecided => Critical

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

Title:
  [SRU] ldap search should not encode attributes

Status in Ubuntu Cloud Archive:
  Fix Committed
Status in Ubuntu Cloud Archive rocky series:
  Triaged
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystone package in Ubuntu:
  Fix Released
Status in keystone source package in Cosmic:
  Triaged

Bug description:
  [Impact]

  Listing user fails with LDAP backend fails
  --

  $ openstack user list --debug --domain userdomain
  Request returned failure status: 400
  ('attrs_from_List(): expected string in list', b'mail') (HTTP 400) 
(Request-ID: req-914f8010-3ed2-4200-a394-5b1bc5158b98)
  Traceback (most recent call last):
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/cliff/app.py",
 line 401, in run_subcommand
  result = cmd.run(parsed_args)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/osc_lib/command/command.py",
 line 41, in run
  return super(Command, self).run(parsed_args)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/cliff/display.py",
 line 116, in run
  column_names, data = self.take_action(parsed_args)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/openstackclient/identity/v3/user.py",
 line 266, in take_action
  group=group,
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/debtcollector/renames.py",
 line 43, in decorator
  return wrapped(*args, **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneclient/v3/users.py",
 line 136, in list
  **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneclient/base.py",
 line 86, in func
  return f(*args, **new_kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneclient/base.py",
 line 444, in list
  list_resp = self._list(url_query, self.collection_key)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneclient/base.py",
 line 141, in _list
  resp, body = self.client.get(url, **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneauth1/adapter.py",
 line 351, in get
  return self.request(url, 'GET', **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneauth1/adapter.py",
 line 510, in request
  resp = super(LegacyJsonAdapter, self).request(*args, **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneauth1/adapter.py",
 line 213, in request
  return self.session.request(url, method, **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneauth1/session.py",
 line 869, in request
  raise exceptions.from_response(resp, method, url)
  keystoneauth1.exceptions.http.BadRequest: ('attrs_from_List(): expected 
string in list', b'mail') (HTTP 400) (Request-ID: 
req-914f8010-3ed2-4200-a394-5b1bc5158b98)
  clean_up ListUser: ('attrs_from_List(): expected string in list', b'mail') 
(HTTP 400) (Request-ID: req-914f8010-3ed2-4200-a394-5b1bc5158b98)
  Traceback (most recent call last):
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/osc_lib/shell.py",
 line 136, in run
  ret_val = super(OpenStackShell, self).run(argv)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/cliff/app.py",
 line 281, in run
  result = self.run_subcommand(remainder)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/osc_lib/shell.py",
 line 176, in run_subcommand
  ret_value = super(OpenStackShell, self).run_subcommand(argv)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/cliff/app.py",
 line 401, in run_subcommand
  result = cmd.run(parsed_args)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/osc_lib/command/command.py",
 line 41, in run
  return super(Command, self).run(parsed_args)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/cliff/display.py",
 line 116, in run
  column_names, data = self.take_action(

[Yahoo-eng-team] [Bug 1803498] Re: node_staging_uri needs the file store to be configured

2019-03-19 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/618468
Committed: 
https://git.openstack.org/cgit/openstack/glance/commit/?id=c92724608512d42b56152d199cc0fea049e4d4a7
Submitter: Zuul
Branch:master

commit c92724608512d42b56152d199cc0fea049e4d4a7
Author: Abhishek Kekane 
Date:   Wed Mar 13 18:12:42 2019 +

Data remains in staging area if 'file' store is not enabled

When operator has not enabled 'file' store and using other stores like ceph,
swift etc. the uploading to staging area works as we explicitly
build 'file' store during this operation, while cleaning up we directly
use 'glance_store.delete_from_backend' which only works if 'file'
store is enabled.

Modified '_DeleteFromFS' task and _unstage call which will use os
module to unlink the file present in staging area explicitly to
delete the data from staging area.

Closes-Bug: #1803498
Change-Id: If0b3b0af9300301291758c67267890e0959ebb3c


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

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

Title:
  node_staging_uri needs the file store to be configured

Status in Glance:
  Fix Released

Bug description:
  If you set node_staging_uri=file:///var/lib/glance/staging and try to
  do a web-download import without the file store enabled, this is
  logged:

  
   Traceback (most recent call last):
 File 
"/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/executor.py", 
line 53, in _execute_task
   result = task.execute(**arguments)
 File 
"/usr/lib/python2.7/site-packages/glance/async_/flows/api_image_import.py", 
line 92, in execute
   store_api.delete_from_backend(file_path)
 File "/usr/lib/python2.7/site-packages/glance_store/backend.py", line 409, 
in delete_from_backend
   loc = location.get_location_from_uri(uri, conf=CONF)
 File "/usr/lib/python2.7/site-packages/glance_store/location.py", line 75, 
in get_location_from_uri
   raise exceptions.UnknownScheme(scheme=pieces.scheme)
   UnknownScheme: Unknown scheme 'file' found in URI

  
  The consequence is that the staging area is not cleaned up, and files are 
piling up. The store should probably be automatically configured.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1803498/+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 1820333] Re: [SRU] ldap search should not encode attributes

2019-03-19 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/643670
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=d6df1dff3e519a26c1a12b6c32f9799484be5966
Submitter: Zuul
Branch:master

commit d6df1dff3e519a26c1a12b6c32f9799484be5966
Author: Corey Bryant 
Date:   Mon Mar 18 13:46:37 2019 -0400

PY3: Ensure LDAP searches use unicode attributes

This is a bug fix that corresponds to changes missed in commit
eca0829c4c65e6b64f08023ce2d5a55dc329248f.

In Python 3, python-ldap no longer allows bytes for some fields (DNs,
RDNs, attribute names, queries). Instead, text values are represented
as str, the Unicode text type. Compatibility support is provided for
Python 2 by setting bytes_mode=False [1]. This support was provided
in commit eca0829c4c65e6b64f08023ce2d5a55dc329248f.

In this patch we ensure that attribute names specified in searches
are no longer encoded.

[1] More details about byte/str usage in python-ldap can be found at:
http://www.python-ldap.org/en/latest/bytes_mode.html#bytes-mode

Change-Id: If3398e2d08ea14fa4b8c498b2a9a7c7edb47b9e5
Closes-Bug: #1820333


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

Title:
  [SRU] ldap search should not encode attributes

Status in Ubuntu Cloud Archive:
  Fix Committed
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystone package in Ubuntu:
  Fix Released

Bug description:
  [Impact]

  Listing user fails with LDAP backend fails
  --

  $ openstack user list --debug --domain userdomain
  Request returned failure status: 400
  ('attrs_from_List(): expected string in list', b'mail') (HTTP 400) 
(Request-ID: req-914f8010-3ed2-4200-a394-5b1bc5158b98)
  Traceback (most recent call last):
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/cliff/app.py",
 line 401, in run_subcommand
  result = cmd.run(parsed_args)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/osc_lib/command/command.py",
 line 41, in run
  return super(Command, self).run(parsed_args)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/cliff/display.py",
 line 116, in run
  column_names, data = self.take_action(parsed_args)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/openstackclient/identity/v3/user.py",
 line 266, in take_action
  group=group,
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/debtcollector/renames.py",
 line 43, in decorator
  return wrapped(*args, **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneclient/v3/users.py",
 line 136, in list
  **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneclient/base.py",
 line 86, in func
  return f(*args, **new_kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneclient/base.py",
 line 444, in list
  list_resp = self._list(url_query, self.collection_key)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneclient/base.py",
 line 141, in _list
  resp, body = self.client.get(url, **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneauth1/adapter.py",
 line 351, in get
  return self.request(url, 'GET', **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneauth1/adapter.py",
 line 510, in request
  resp = super(LegacyJsonAdapter, self).request(*args, **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneauth1/adapter.py",
 line 213, in request
  return self.session.request(url, method, **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneauth1/session.py",
 line 869, in request
  raise exceptions.from_response(resp, method, url)
  keystoneauth1.exceptions.http.BadRequest: ('attrs_from_List(): expected 
string in list', b'mail') (HTTP 400) (Request-ID: 
req-914f8010-3ed2-4200-a394-5b1bc5158b98)
  clean_up ListUser: ('attrs_from_List(): expected string in list', b'mail') 
(HTTP 400) (Request-ID: req-914f8010-3ed2-4200-a394-5b1bc5158b98)
  Traceback (most recent call last):
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/osc_lib/shell.py",
 line 136, in run
  ret_val = super(OpenStackShell, self).run(argv)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/cliff/app.py",
 line 281, in run
  result = self.run_subcommand(remainder)
    File 
"/home/ubuntu/charm-

[Yahoo-eng-team] [Bug 1820333] Re: [SRU] ldap search should not encode attributes

2019-03-19 Thread Launchpad Bug Tracker
This bug was fixed in the package keystone - 2:15.0.0~b1~git2019031401
.2c7bb275f-0ubuntu2

---
keystone (2:15.0.0~b1~git2019031401.2c7bb275f-0ubuntu2) disco; urgency=medium

  * d/p/ensure-LDAP-searches-use-unicode-attributes.patch: Cherry-picked
from https://review.openstack.org/#/c/643670/ to fix LDAP backend
searches (LP: #1820333).

 -- Corey Bryant   Tue, 19 Mar 2019 07:26:22
-0400

** Changed in: keystone (Ubuntu)
   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/1820333

Title:
  [SRU] ldap search should not encode attributes

Status in Ubuntu Cloud Archive:
  Fix Committed
Status in OpenStack Identity (keystone):
  In Progress
Status in keystone package in Ubuntu:
  Fix Released

Bug description:
  [Impact]

  Listing user fails with LDAP backend fails
  --

  $ openstack user list --debug --domain userdomain
  Request returned failure status: 400
  ('attrs_from_List(): expected string in list', b'mail') (HTTP 400) 
(Request-ID: req-914f8010-3ed2-4200-a394-5b1bc5158b98)
  Traceback (most recent call last):
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/cliff/app.py",
 line 401, in run_subcommand
  result = cmd.run(parsed_args)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/osc_lib/command/command.py",
 line 41, in run
  return super(Command, self).run(parsed_args)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/cliff/display.py",
 line 116, in run
  column_names, data = self.take_action(parsed_args)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/openstackclient/identity/v3/user.py",
 line 266, in take_action
  group=group,
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/debtcollector/renames.py",
 line 43, in decorator
  return wrapped(*args, **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneclient/v3/users.py",
 line 136, in list
  **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneclient/base.py",
 line 86, in func
  return f(*args, **new_kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneclient/base.py",
 line 444, in list
  list_resp = self._list(url_query, self.collection_key)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneclient/base.py",
 line 141, in _list
  resp, body = self.client.get(url, **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneauth1/adapter.py",
 line 351, in get
  return self.request(url, 'GET', **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneauth1/adapter.py",
 line 510, in request
  resp = super(LegacyJsonAdapter, self).request(*args, **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneauth1/adapter.py",
 line 213, in request
  return self.session.request(url, method, **kwargs)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/keystoneauth1/session.py",
 line 869, in request
  raise exceptions.from_response(resp, method, url)
  keystoneauth1.exceptions.http.BadRequest: ('attrs_from_List(): expected 
string in list', b'mail') (HTTP 400) (Request-ID: 
req-914f8010-3ed2-4200-a394-5b1bc5158b98)
  clean_up ListUser: ('attrs_from_List(): expected string in list', b'mail') 
(HTTP 400) (Request-ID: req-914f8010-3ed2-4200-a394-5b1bc5158b98)
  Traceback (most recent call last):
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/osc_lib/shell.py",
 line 136, in run
  ret_val = super(OpenStackShell, self).run(argv)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/cliff/app.py",
 line 281, in run
  result = self.run_subcommand(remainder)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/osc_lib/shell.py",
 line 176, in run_subcommand
  ret_value = super(OpenStackShell, self).run_subcommand(argv)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/cliff/app.py",
 line 401, in run_subcommand
  result = cmd.run(parsed_args)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/osc_lib/command/command.py",
 line 41, in run
  return super(Command, self).run(parsed_args)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/site-packages/cliff/display.py",
 line 116, in run
  column_names, data = self.take_action(parsed_args)
    File 
"/home/ubuntu/charm-test-infra/.tox/clients/lib/python3.6/si

[Yahoo-eng-team] [Bug 1820870] [NEW] Fullstack tests are failing with error connection to rabbitmq

2019-03-19 Thread Slawek Kaplonski
Public bug reported:

Various fullstack tests are failing because of some issues with
connection to rabbitmq.

Example of such failure: http://logs.openstack.org/86/643486/8/check
/neutron-fullstack/9fe648e/logs/testr_results.html.gz and log from
agents: http://logs.openstack.org/86/643486/8/check/neutron-
fullstack/9fe648e/logs/dsvm-fullstack-
logs/TestDscpMarkingQoSLinuxbridge.test_dscp_marking_clean_port_removed
/neutron-linuxbridge-agent--2019-03-19--
12-12-33-931856.txt.gz?level=ERROR

All agents in such case can't connect to rabbitmq, errors in logs are
like:

AMQP server on 240.44.122.1:5672 is unreachable: [Errno 101]
ENETUNREACH. Trying again in 4 seconds.: OSError: [Errno 101]
ENETUNREACH

Logstash query:
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22ENETUNREACH%5C%22%20AND%20build_name%3A%5C
%22neutron-fullstack%5C%22

** Affects: neutron
 Importance: High
 Status: Confirmed


** Tags: fullstack

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

Title:
  Fullstack tests are failing with error connection to rabbitmq

Status in neutron:
  Confirmed

Bug description:
  Various fullstack tests are failing because of some issues with
  connection to rabbitmq.

  Example of such failure: http://logs.openstack.org/86/643486/8/check
  /neutron-fullstack/9fe648e/logs/testr_results.html.gz and log from
  agents: http://logs.openstack.org/86/643486/8/check/neutron-
  fullstack/9fe648e/logs/dsvm-fullstack-
  logs/TestDscpMarkingQoSLinuxbridge.test_dscp_marking_clean_port_removed
  /neutron-linuxbridge-agent--2019-03-19--
  12-12-33-931856.txt.gz?level=ERROR

  All agents in such case can't connect to rabbitmq, errors in logs are
  like:

  AMQP server on 240.44.122.1:5672 is unreachable: [Errno 101]
  ENETUNREACH. Trying again in 4 seconds.: OSError: [Errno 101]
  ENETUNREACH

  Logstash query:
  
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22ENETUNREACH%5C%22%20AND%20build_name%3A%5C
  %22neutron-fullstack%5C%22

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1820870/+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 1820865] [NEW] Fullstack tests are failing because of "OSError: [Errno 22] failed to open netns"

2019-03-19 Thread Slawek Kaplonski
Public bug reported:

Example of failure: http://logs.openstack.org/52/586252/36/check
/neutron-fullstack/daab6f7/job-output.txt.gz

Test traceback:
 Captured traceback:
2019-03-17 15:28:33.814167 | primary | 2019-03-17 15:28:33.813 | 
~~~
2019-03-17 15:28:33.816364 | primary | 2019-03-17 15:28:33.815 | 
b'Traceback (most recent call last):'
2019-03-17 15:28:33.818734 | primary | 2019-03-17 15:28:33.818 | b'  File 
"/opt/stack/new/neutron/neutron/tests/base.py", line 174, in func'
2019-03-17 15:28:33.820703 | primary | 2019-03-17 15:28:33.820 | b'
return f(self, *args, **kwargs)'
2019-03-17 15:28:33.823297 | primary | 2019-03-17 15:28:33.822 | b'  File 
"/opt/stack/new/neutron/neutron/tests/fullstack/test_l3_agent.py", line 166, in 
test_mtu_update'
2019-03-17 15:28:33.825622 | primary | 2019-03-17 15:28:33.825 | b'
common_utils.wait_until_true(lambda: ip.get_devices())'
2019-03-17 15:28:33.827812 | primary | 2019-03-17 15:28:33.827 | b'  File 
"/opt/stack/new/neutron/neutron/common/utils.py", line 684, in wait_until_true'
2019-03-17 15:28:33.829764 | primary | 2019-03-17 15:28:33.829 | b'
while not predicate():'
2019-03-17 15:28:33.831982 | primary | 2019-03-17 15:28:33.831 | b'  File 
"/opt/stack/new/neutron/neutron/tests/fullstack/test_l3_agent.py", line 166, in 
'
2019-03-17 15:28:33.834421 | primary | 2019-03-17 15:28:33.833 | b'
common_utils.wait_until_true(lambda: ip.get_devices())'
2019-03-17 15:28:40.262004 | primary | 2019-03-17 15:28:40.261 | b'  File 
"/opt/stack/new/neutron/neutron/agent/linux/ip_lib.py", line 162, in 
get_devices'
2019-03-17 15:28:40.263952 | primary | 2019-03-17 15:28:40.263 | b'
devices = privileged.get_device_names(self.namespace)'
2019-03-17 15:28:40.266330 | primary | 2019-03-17 15:28:40.265 | b'  File 
"/opt/stack/new/neutron/neutron/privileged/agent/linux/ip_lib.py", line 567, in 
get_device_names'
2019-03-17 15:28:40.268162 | primary | 2019-03-17 15:28:40.267 | b'in 
get_link_devices(namespace, **kwargs)]'
2019-03-17 15:28:40.270638 | primary | 2019-03-17 15:28:40.269 | b'  File 
"/opt/stack/new/neutron/.tox/dsvm-fullstack/lib/python3.6/site-packages/oslo_privsep/priv_context.py",
 line 241, in _wrap'
2019-03-17 15:28:40.272582 | primary | 2019-03-17 15:28:40.272 | b'
return self.channel.remote_call(name, args, kwargs)'
2019-03-17 15:28:40.274822 | primary | 2019-03-17 15:28:40.274 | b'  File 
"/opt/stack/new/neutron/.tox/dsvm-fullstack/lib/python3.6/site-packages/oslo_privsep/daemon.py",
 line 203, in remote_call'
2019-03-17 15:28:40.276631 | primary | 2019-03-17 15:28:40.276 | b'
raise exc_type(*result[2])'
2019-03-17 15:28:40.278636 | primary | 2019-03-17 15:28:40.278 | b'OSError: 
[Errno 22] failed to open netns'


Logstash query: 
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22failed%20to%20open%20netns%5C%22%20AND%20build_name%3A%5C%22neutron-fullstack%5C%22

** Affects: neutron
 Importance: Critical
 Status: Confirmed


** Tags: fullstack

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

Title:
  Fullstack tests are failing because of "OSError: [Errno 22] failed to
  open netns"

Status in neutron:
  Confirmed

Bug description:
  Example of failure: http://logs.openstack.org/52/586252/36/check
  /neutron-fullstack/daab6f7/job-output.txt.gz

  Test traceback:
   Captured traceback:
  2019-03-17 15:28:33.814167 | primary | 2019-03-17 15:28:33.813 | 
~~~
  2019-03-17 15:28:33.816364 | primary | 2019-03-17 15:28:33.815 | 
b'Traceback (most recent call last):'
  2019-03-17 15:28:33.818734 | primary | 2019-03-17 15:28:33.818 | b'  File 
"/opt/stack/new/neutron/neutron/tests/base.py", line 174, in func'
  2019-03-17 15:28:33.820703 | primary | 2019-03-17 15:28:33.820 | b'
return f(self, *args, **kwargs)'
  2019-03-17 15:28:33.823297 | primary | 2019-03-17 15:28:33.822 | b'  File 
"/opt/stack/new/neutron/neutron/tests/fullstack/test_l3_agent.py", line 166, in 
test_mtu_update'
  2019-03-17 15:28:33.825622 | primary | 2019-03-17 15:28:33.825 | b'
common_utils.wait_until_true(lambda: ip.get_devices())'
  2019-03-17 15:28:33.827812 | primary | 2019-03-17 15:28:33.827 | b'  File 
"/opt/stack/new/neutron/neutron/common/utils.py", line 684, in wait_until_true'
  2019-03-17 15:28:33.829764 | primary | 2019-03-17 15:28:33.829 | b'
while not predicate():'
  2019-03-17 15:28:33.831982 | primary | 2019-03-17 15:28:33.831 | b'  File 
"/opt/stack/new/neutron/neutron/tests/fullstack/test_l3_agent.py", line 166, in 
'
  2019-03-17 15:28:33.834421 | primary | 2019-03-17 15:28:33.833 | b'
common_utils.wait_until_true(lambda: ip.get_devices())'
  2019-03-17 15:28:40.262004 | primary | 2019-03-17 15:28:40.261 | b'  File 
"/opt/stack/new/ne

[Yahoo-eng-team] [Bug 1819957] Re: Caching with stale data when a server disconnects due to network partition and reconnects

2019-03-19 Thread Jeremy Stanley
Unless there's a way for a malicious actor to trigger and take advantage
of this condition, this is probably a class D (security hardening
opportunity) report: https://security.openstack.org/vmt-process.html
#incident-report-taxonomy

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

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

** Information type changed from Public Security to Public

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

Title:
  Caching with stale data when a server disconnects due to network
  partition and reconnects

Status in OpenStack Identity (keystone):
  Triaged
Status in keystonemiddleware:
  Triaged
Status in oslo.cache:
  New
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  The flush_on_reconnect optional flag is not used. This can cause stale
  data to be utilized from a cache server that disconnected due to a
  network partition. This has security concerns as follows:

  1*  Password changes/user changes may be reverted for the cache TTL
  1a* User may get locked out if PCI-DSS is on and the password change happens 
during the network
  partition.
  2*  Grant changes may be reverted for the cache TTL
  3*  Resources (all types) may become "undeleted" for the cache TTL
  4*  Tokens (KSM) may become valid again during the cache TTL

  
  As noted in the python-memcached library:

  @param flush_on_reconnect: optional flag which prevents a
  scenario that can cause stale data to be read: If there's more
  than one memcached server and the connection to one is
  interrupted, keys that mapped to that server will get
  reassigned to another. If the first server comes back, those
  keys will map to it again. If it still has its data, get()s
  can read stale data that was overwritten on another
  server. This flag is off by default for backwards
  compatibility.

  The solution is to explicitly pass flush_on_reconnect as an optional
  argument. A concern with this model is that the memcached servers may
  be utilized by other tooling and may lose cache state (in the case the
  oslo.cache connection is the only thing affected by the network
  partitioning).

  This similarly needs to be addressed in pymemcache when it is utilized
  in lieu of python-memcached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1819957/+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 1820851] Re: Please do cell mapping without periodic task or active admin involvment

2019-03-19 Thread Matt Riedemann
discover_hosts_in_cells_interval is not mandatory, and discover_hosts
can be run in deployment tooling when a new compute node is deployed.
One of the goals of cells v2 is isolation from the cell to the API DB,
so for the cell to be able to register itself with the API DB would
require an "up-call" to the API DB to do so which violates that
isolation.

** Tags added: cells

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

Title:
  Please do cell mapping without periodic task or active admin
  involvment

Status in OpenStack Compute (nova):
  Opinion

Bug description:
  'nova-manage cell_v2 discover_hosts' usage should not be needed,
  the compute nodes at start up time could ask for registration
   and not repeat it during the n-cpu process lifetime.

  In case of you have 30k compute node and restarting
  them every two week in average, it would generate
  ~ 0.03 avg. request per sec. 

  I do not see why it is mandatory to use

  nova-manage cell_v2 discover_hosts  or 
  [scheduler]
  discover_hosts_in_cells_interval = 300

  even in a small deployment.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1820851/+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 1820851] [NEW] Please do cell mapping without periodic task or active admin involvment

2019-03-19 Thread Attila Fazekas
Public bug reported:

'nova-manage cell_v2 discover_hosts' usage should not be needed,
the compute nodes at start up time could ask for registration
 and not repeat it during the n-cpu process lifetime.

In case of you have 30k compute node and restarting
them every two week in average, it would generate
~ 0.03 avg. request per sec. 

I do not see why it is mandatory to use

nova-manage cell_v2 discover_hosts  or 
[scheduler]
discover_hosts_in_cells_interval = 300

even in a small deployment.

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

Title:
  Please do cell mapping without periodic task or active admin
  involvment

Status in OpenStack Compute (nova):
  New

Bug description:
  'nova-manage cell_v2 discover_hosts' usage should not be needed,
  the compute nodes at start up time could ask for registration
   and not repeat it during the n-cpu process lifetime.

  In case of you have 30k compute node and restarting
  them every two week in average, it would generate
  ~ 0.03 avg. request per sec. 

  I do not see why it is mandatory to use

  nova-manage cell_v2 discover_hosts  or 
  [scheduler]
  discover_hosts_in_cells_interval = 300

  even in a small deployment.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1820851/+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 1820827] [NEW] neutron-vpnaas :ipsec site connection pending create

2019-03-19 Thread hanbo
Public bug reported:

Openstack release is pike in ubuntu16.04.
After 
sudo apt-get install python-neutron-vpnaas
sudo apt-get install strongswan
I didn't get a file named /usr/lib/neutron-vpn-agent or 
/etc/neutron/vpn-agent.ini.
Then I edit /etc/neutron/neutron.conf 
service = vpnaas

/etc/neutron/neutron_vpnaas.conf
service_provider = 
VPN:strongswan:neutron_vpnaas.services.vpn.service_drivers.ipsec.IPsecVPNDriver:default

/etc/neutron/l3-agent.ini
[AGENT]
extensions = vpnaas

[vpnagent]
vpn_device_driver = 
neutron_vpnaas.services.vpn.device_drivers.strongswan_ipsec.StrongSwanDriver

systemctl restart neutron-server
systemctl restart neutron-l3-agent

/var/log/neutron/neutron-server.log

2019-03-19 17:53:50.988 10977 WARNING stevedore.named [req-
bfb9dc35-98e2-4b93-9190-fb361ec162a0 - - - - -] Could not load
neutron_vpnaas.services.vpn.service_drivers.ipsec.IPsecVPNDriver

/var/log/neutron/neutron-l3-agent.log

2019-03-19 17:53:13.979 10901 WARNING stevedore.named [req-
46c236d1-02c2-4d05-a644-b1603f7b73cd - - - - -] Could not load vpnaas

** Affects: neutron
 Importance: Undecided
 Status: New

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

Title:
  neutron-vpnaas :ipsec site connection  pending create

Status in neutron:
  New

Bug description:
  Openstack release is pike in ubuntu16.04.
  After 
  sudo apt-get install python-neutron-vpnaas
  sudo apt-get install strongswan
  I didn't get a file named /usr/lib/neutron-vpn-agent or 
/etc/neutron/vpn-agent.ini.
  Then I edit /etc/neutron/neutron.conf 
  service = vpnaas

  /etc/neutron/neutron_vpnaas.conf
  service_provider = 
VPN:strongswan:neutron_vpnaas.services.vpn.service_drivers.ipsec.IPsecVPNDriver:default

  /etc/neutron/l3-agent.ini
  [AGENT]
  extensions = vpnaas

  [vpnagent]
  vpn_device_driver = 
neutron_vpnaas.services.vpn.device_drivers.strongswan_ipsec.StrongSwanDriver

  systemctl restart neutron-server
  systemctl restart neutron-l3-agent

  /var/log/neutron/neutron-server.log

  2019-03-19 17:53:50.988 10977 WARNING stevedore.named [req-
  bfb9dc35-98e2-4b93-9190-fb361ec162a0 - - - - -] Could not load
  neutron_vpnaas.services.vpn.service_drivers.ipsec.IPsecVPNDriver

  /var/log/neutron/neutron-l3-agent.log

  2019-03-19 17:53:13.979 10901 WARNING stevedore.named [req-
  46c236d1-02c2-4d05-a644-b1603f7b73cd - - - - -] Could not load vpnaas

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1820827/+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 1697163] Re: glance CLI doesn'tconsider anymore OS_CACERT

2019-03-19 Thread Pavlo Shchelokovskyy
I believe we can close this, fix to glanceclient was merged >1y ago.

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

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

Title:
  glance CLI doesn'tconsider anymore OS_CACERT

Status in Glance:
  Fix Released

Bug description:
  Not sure if the glance cli is still supported, but it looks like
  glance CLI provided with Ocata (the relavent RPM is
  python2-glanceclient-2.6.0-1.el7.noarch) doesn't read anymore the
  OS_CACERT, as it used to do.

  Now it is necessary to use the "--os-cacert" option:

  [root@controller-01 ~]# glance image-list
  SSL exception connecting to 
https://cloud-areapd-test.pd.infn.it:35357/v3/auth/tokens: [SSL: 
CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579)

  [root@controller-01 ~]# glance --os-cacert ${OS_CACERT} image-list
  +--+---+
  | ID   | Name  |
  +--+---+
  | 940c4c27-bd2c-4a16-a751-5f725d6b12ef |   |
  | df7b5ac0-f9f3-42fb-9650-a2d3d863b042 |   |
  | 739dd37b-374b-40e3-9b2f-66b54aaa5670 |   |
  etc etc

  "openstack image list" works as expected

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