[Yahoo-eng-team] [Bug 1082248] Re: Use uuidutils instead of uuid.uuid4()

2016-11-30 Thread John Dickinson
** Changed in: swift
   Status: New => Won't Fix

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

Title:
  Use uuidutils instead of uuid.uuid4()

Status in Cinder:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in Karbor:
  Fix Released
Status in kolla:
  Fix Committed
Status in kuryr:
  Fix Released
Status in kuryr-libnetwork:
  Fix Released
Status in Magnum:
  In Progress
Status in Mistral:
  Fix Released
Status in networking-calico:
  In Progress
Status in networking-ovn:
  Fix Released
Status in networking-sfc:
  In Progress
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  In Progress
Status in Sahara:
  Fix Released
Status in senlin:
  Fix Released
Status in OpenStack Object Storage (swift):
  Won't Fix
Status in tacker:
  In Progress
Status in watcher:
  Fix Released

Bug description:
  Openstack common has a wrapper for generating uuids.

  We should only use that function when generating uuids for
  consistency.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1082248/+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 1277104] Re: wrong order of assertEquals args

2015-12-04 Thread John Dickinson
** Changed in: python-swiftclient
   Status: Fix Committed => 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/1277104

Title:
  wrong order of assertEquals args

Status in Ceilometer:
  Fix Released
Status in Cinder:
  Fix Released
Status in Glance:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in oslo.messaging:
  Fix Released
Status in oslo.policy:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-ironicclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in Python client library for Sahara:
  Fix Released
Status in python-swiftclient:
  Won't Fix
Status in python-troveclient:
  Fix Released
Status in Rally:
  Confirmed
Status in Trove:
  Fix Released

Bug description:
  Args of assertEquals method in ceilometer.tests are arranged in wrong order. 
In result when test fails it shows incorrect information about observed and 
actual data. It's found more than 2000 times.
  Right order of arguments is "expected, actual".

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1277104/+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 1179008] Re: rename requires files to standard names

2015-07-15 Thread John Dickinson
** Changed in: python-swiftclient
   Status: Fix Committed = 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/1179008

Title:
  rename requires files to standard names

Status in Ceilometer:
  Fix Released
Status in Cinder:
  Fix Released
Status in Gear:
  New
Status in git-review:
  Fix Committed
Status in Glance:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Keystone:
  Fix Released
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in oslo-incubator:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  Fix Committed
Status in python-keystoneclient:
  Fix Released
Status in python-neutronclient:
  Fix Committed
Status in python-novaclient:
  Fix Released
Status in python-openstackclient:
  Fix Committed
Status in python-swiftclient:
  Fix Released
Status in Python client library for Zaqar:
  In Progress
Status in OpenStack Object Storage (swift):
  Fix Released
Status in Trove:
  Fix Released
Status in Zuul:
  In Progress

Bug description:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1

  Rename tools/pip-requires to requirements.txt and tools/test-requires
  to test-requirements.txt. These are standard files and tools in the
  general world are growing intelligence about them.

   affects ceilometer
   affects cinder
   affects git-review
   affects glance
   affects heat-cfntools
   affects heat
   affects horizon
   affects keystone
   affects nova
   affects openstack-ci
   affects oslo
   affects python-ceilometerclient
   affects python-cinderclient
   affects python-gear
   affects python-glanceclient
   affects python-heatclient
   affects python-keystoneclient
   affects python-novaclient
   affects python-openstackclient
   affects python-quantumclient
   affects python-swiftclient
   affects quantum
   affects reddwarf
   affects swift
   affects tempest
   affects zuul
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.12 (GNU/Linux)
  Comment: Using GnuPG with undefined - http://www.enigmail.net/

  iEYEARECAAYFAlGObegACgkQ2Jv7/VK1RgH+yQCbBuxIZvk/Ra4TEK0TlLqr3xAU
  cj8An1NPMiQ47VubNdsKg6ybymtRRjto
  =fwhb
  -END PGP SIGNATURE-

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1179008/+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 1268439] Re: range method is not same in py3.x and py2.x

2015-07-15 Thread John Dickinson
** Changed in: python-swiftclient
   Status: Fix Committed = 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/1268439

Title:
  range method is not same in py3.x and py2.x

Status in Ceilometer:
  Fix Released
Status in Cinder:
  In Progress
Status in Glance:
  Fix Released
Status in heat:
  Fix Released
Status in Keystone:
  In Progress
Status in neutron:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-neutronclient:
  Invalid
Status in python-swiftclient:
  Fix Released
Status in OpenStack Object Storage (swift):
  In Progress

Bug description:
  in py3.x,range is xrange in py2.x.
  in py3.x, if you want get a list,you must use:
  list(range(value))

  I review the code, find that many codes use range for  loop, if used py3.x 
environment,
  it will occure error.
  so we must modify this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1268439/+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 1008940] Re: Need full unicode support for Swift

2015-07-15 Thread John Dickinson
** Changed in: python-swiftclient
   Status: Fix Committed = Fix Released

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

Title:
  Need full unicode support for Swift

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in python-swiftclient:
  Fix Released

Bug description:
  This error  can be reproduced in two cases:
  1. copy an object to/from the container with Unicode character in its name, 
e.g.  Japanese or Chinese character.
  2. copy an object with Unicode character in its name

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1008940/+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 1179007] Re: Migrate build system to pbr

2015-07-15 Thread John Dickinson
** Changed in: python-swiftclient
   Status: Fix Committed = 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/1179007

Title:
  Migrate build system to pbr

Status in Ceilometer:
  Fix Released
Status in Cinder:
  Fix Released
Status in Gear:
  New
Status in git-review:
  Fix Committed
Status in heat:
  Fix Released
Status in heat-cfntools:
  Fix Released
Status in Keystone:
  Fix Released
Status in neutron:
  Fix Released
Status in oslo-incubator:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  Fix Committed
Status in python-heatclient:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in python-neutronclient:
  Fix Committed
Status in python-novaclient:
  Fix Released
Status in python-openstackclient:
  Fix Committed
Status in python-swiftclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Committed
Status in OpenStack Object Storage (swift):
  Fix Released
Status in Trove:
  Fix Released
Status in Zuul:
  New

Bug description:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1

  openstack.common.setup and openstack.common.version are now in the
  standalone library pbr. Migrating involves moving build config to
  setup.cfg, copying in a stub setup.py file, adding pbr and d2to1 to the
  build depends, removing openstack.common.(setup|version) from the
  filesystem and from openstack-common.conf and making sure *.egg is in
  .gitignore.

   affects ceilometer
   affects cinder
   affects git-review
   affects heat-cfntools
   affects heat
   affects keystone
   affects openstack-ci
   affects oslo
   affects python-ceilometerclient
   affects python-cinderclient
   affects python-gear
   affects python-glanceclient
   affects python-heatclient
   affects python-keystoneclient
   affects python-novaclient
   affects python-openstackclient
   affects python-quantumclient
   affects python-swiftclient
   affects reddwarf
   affects swift
   affects zuul
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.12 (GNU/Linux)
  Comment: Using GnuPG with undefined - http://www.enigmail.net/

  iEYEARECAAYFAlGObdUACgkQ2Jv7/VK1RgFlkACgzycOW0/rPvnLaXXX9/oqYA7q
  kGEAoMaEzGbFEAnsQA6+cEsKIUSMWAPD
  =W8F0
  -END PGP SIGNATURE-

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1179007/+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 1266513] Re: Some Python requirements are not hosted on PyPI

2015-07-13 Thread John Dickinson
** Changed in: swift
   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/1266513

Title:
  Some Python requirements are not hosted on PyPI

Status in Glance:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Keystone:
  Fix Released
Status in Keystone havana series:
  Fix Released
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in OpenStack Object Storage (swift):
  Fix Released
Status in tripleo:
  Fix Released

Bug description:
  Pip 1.5 (released January 2nd, 2014) will by default refuse to
  download packages which are linked from PyPI but not hosted on
  pypi.python.org. The workaround is to whitelist these package names
  individually with both the --allow-external and --allow-insecure
  options.

  These options are new in pip 1.4, so encoding them will break for
  people trying to use pip 1.3.x or earlier. Those earlier versions of
  pip are not secure anyway since they don't connect via HTTPS with host
  certificate validation, so we should be encouraging people to use 1.4
  and later anyway.

  The --allow-insecure option is transitioning to a clearer --allow-
  unverified option name starting with 1.5, but the new form does not
  work with pip before 1.5 so we should use the old version for now to
  allow people to transition gracefully. The --allow-insecure form won't
  be removed until at least pip 1.7 according to comments in the source
  code.

  Virtualenv 1.11 (released the same day) bundles pip 1.5 by default,
  and so requires these workarounds when using requirements external to
  PyPI. Be aware that 1.11 is broken for projects using
  sitepackages=True in their tox.ini. The fix is
  https://github.com/pypa/virtualenv/commit/a6ca6f4 which is slated to
  appear in 1.11.1 (no ETA available). We've worked around it on our
  test infrastructure with https://git.openstack.org/cgit/openstack-
  infra/config/commit/?id=20cd18a for now, but that is hiding the
  external-packages issue since we're currently running all tests with
  pip 1.4.1 as a result.

  This bug will also be invisible in our test infrastructure for
  projects listed as having the PyPI mirror enforced in
  openstack/requirements (except for jobs which bypass the mirror, such
  as those for requirements changes), since our update jobs will pull in
  and mirror external packages and pip sees the mirror as being PyPI
  itself in that situation.

  We'll use this bug to track necessary whitelist updates to tox.ini and
  test scripts.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1266513/+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 1469974] Re: kilo version swift doesn't work showing swiftclient:Authorrization Failure the resource could not be found

2015-07-06 Thread John Dickinson
** No longer affects: swift

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

Title:
  kilo version swift doesn't work showing swiftclient:Authorrization
  Failure the resource could not be found

Status in OpenStack Identity (Keystone):
  New
Status in Python client library for Swift:
  Incomplete

Bug description:
  # swift --debug list
  DEBUG:keystoneclient.auth.identity.v2:Making authentication request to 
http://swift-test-keystone:35357/v3/tokens
  INFO:urllib3.connectionpool:Starting new HTTP connection (1): 
swift-test-keystone
  DEBUG:urllib3.connectionpool:POST /v3/tokens HTTP/1.1 404 93
  DEBUG:keystoneclient.session:Request returned failure status: 404
  ERROR:swiftclient:Authorization Failure. Authorization Failed: The resource 
could not be found. (HTTP 404) (Request-ID: 
req-93f815b5-7c3b-462e-b3c9-8c0ecf9f4da3)
  Traceback (most recent call last):
    File /usr/lib/python2.7/dist-packages/swiftclient/client.py, line 1235, 
in _retry
  self.url, self.token = self.get_auth()
    File /usr/lib/python2.7/dist-packages/swiftclient/client.py, line 1209, 
in get_auth
  insecure=self.insecure)
    File /usr/lib/python2.7/dist-packages/swiftclient/client.py, line 406, in 
get_auth
  auth_version=auth_version)
    File /usr/lib/python2.7/dist-packages/swiftclient/client.py, line 341, in 
get_auth_keystone
  raise ClientException('Authorization Failure. %s' % err)
  ClientException: Authorization Failure. Authorization Failed: The resource 
could not be found. (HTTP 404) (Request-ID: 
req-93f815b5-7c3b-462e-b3c9-8c0ecf9f4da3)
  Authorization Failure. Authorization Failed: The resource could not be found. 
(HTTP 404) (Request-ID: req-93f815b5-7c3b-462e-b3c9-8c0ecf9f4da3)

  Setup of this environment is based on installation guide of kilo
  version. The openstack service on keystone node works just fine but
  swift doesn't.

  After then I modified the openstack client enviroment scripts from
  export OS_AUTH_URL=http://controller:35357/v3
  to
  export OS_AUTH_URL=http://controller:35357/v2.0

  the debug info is as below

  DEBUG:keystoneclient.auth.identity.v2:Making authentication request to 
http://swift-test-keystone:35357/v2.0/tokens
  INFO:urllib3.connectionpool:Starting new HTTP connection (1): 
swift-test-keystone
  DEBUG:urllib3.connectionpool:POST /v2.0/tokens HTTP/1.1 200 1213
  DEBUG:iso8601.iso8601:Parsed 2015-06-30T08:21:48Z into {'tz_sign': None, 
'second_fraction': None, 'hour': u'08', 'daydash': u'30', 'tz_hour': None, 
'month': None, 'timezone': u'Z', 'second': u'48', 'tz_minute': None, 'year': 
u'2015', 'separator': u'T', 'monthdash': u'06', 'day': None, 'minute': u'21'} 
with default timezone iso8601.iso8601.Utc object at 0x7f070f511590
  DEBUG:iso8601.iso8601:Got u'2015' for 'year' with default None
  DEBUG:iso8601.iso8601:Got u'06' for 'monthdash' with default 1
  DEBUG:iso8601.iso8601:Got 6 for 'month' with default 6
  DEBUG:iso8601.iso8601:Got u'30' for 'daydash' with default 1
  DEBUG:iso8601.iso8601:Got 30 for 'day' with default 30
  DEBUG:iso8601.iso8601:Got u'08' for 'hour' with default None
  DEBUG:iso8601.iso8601:Got u'21' for 'minute' with default None
  DEBUG:iso8601.iso8601:Got u'48' for 'second' with default None
  INFO:urllib3.connectionpool:Starting new HTTP connection (1): 
swift-test-proxynode1
  DEBUG:urllib3.connectionpool:GET 
/v1/AUTH_c29f928f72f146fc9411e35c515c00a7?format=json HTTP/1.1 401 131
  INFO:swiftclient:REQ: curl -i 
http://swift-test-proxynode1:8080/v1/AUTH_c29f928f72f146fc9411e35c515c00a7?format=json
 -X GET -H X-Auth-Token: a09f170245314c3583c477ac36b5508b
  INFO:swiftclient:RESP STATUS: 401 Unauthorized
  INFO:swiftclient:RESP HEADERS: [('content-length', '131'), ('connection', 
'keep-alive'), ('x-trans-id', 'tx2c1fe6ed35674405a65c3-005592438c'), ('date', 
'Tue, 30 Jun 2015 07:21:48 GMT'), ('content-type', 'text/html; charset=UTF-8'), 
('www-authenticate', 'Swift realm=AUTH_c29f928f72f146fc9411e35c515c00a7')]
  INFO:swiftclient:RESP BODY: htmlh1Unauthorized/h1pThis server could 
not verify that you are authorized to access the document you 
requested./p/html
  DEBUG:keystoneclient.auth.identity.v2:Making authentication request to 
http://swift-test-keystone:35357/v2.0/tokens
  INFO:urllib3.connectionpool:Starting new HTTP connection (1): 
swift-test-keystone
  DEBUG:urllib3.connectionpool:POST /v2.0/tokens HTTP/1.1 200 1213
  DEBUG:iso8601.iso8601:Parsed 2015-06-30T08:21:49Z into {'tz_sign': None, 
'second_fraction': None, 'hour': u'08', 'daydash': u'30', 'tz_hour': None, 
'month': None, 'timezone': u'Z', 'second': u'49', 'tz_minute': None, 'year': 
u'2015', 'separator': u'T', 'monthdash': u'06', 'day': None, 'minute': u'21'} 
with default timezone iso8601.iso8601.Utc object at 0x7f070f511590
  DEBUG:iso8601.iso8601:Got u'2015' for 'year' with default None
  DEBUG:iso8601.iso8601:Got u'06' for 'monthdash' with 

[Yahoo-eng-team] [Bug 1192966] Re: Potentially insecure dependency loading

2015-07-06 Thread John Dickinson
** Changed in: swift
   Status: New = Invalid

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

Title:
  Potentially insecure dependency loading

Status in OpenStack Image Registry and Delivery Service (Glance):
  Invalid
Status in OpenStack Object Storage (Swift):
  Invalid

Bug description:
  Grant Murphy and Dhiru Kholia from Red Hat Product Security Team
  reported the following potential issue. This is actually a setuptools
  issue but which we may be able to workaround, if we end up being
  affected:

  ---
  A security flaw was found in the way Python Setuptools, a collection of 
enhancements to the Python distutils module, that allows more easily to build 
and distribute Python packages, performed integrity checks when loading 
external resources, previously extracted from zipped Python Egg 
archives(formerly if the timestamp and file size of a particular resource 
expanded from the archive matched the original values, the resource was 
successfully loaded). A local attacker, with write permission into the Python's 
EGG cache (directory) could use this flaw to provide a specially-crafted 
resource (in expanded form) that, when loaded in an application requiring that 
resource to (be able to) run, would lead to arbitrary code execution with the 
privileges of the user running the application.

  It seems to be pretty common for Python applications to do something
  like os.evironment['PYTHON_EGG_CACHE'] = /tmp, prior to importing
  dependencies.

  If the dependency contains a .so Python must unpack it into the cache 
directory to be able to load it. However if an attacker pre-emptively places a 
.so in the same location as long as the file has the same timestamp and file 
size it will be loaded.
  ---

  Glance and Swift both set PYTHON_EGG_CACHE to '/tmp' :
  ./glance/glance/cmd/control.py:os.environ['PYTHON_EGG_CACHE'] = '/tmp'
  ./swift/swift/common/manager.py:os.environ['PYTHON_EGG_CACHE'] = '/tmp'

  If we are immediately vulnerable to this (i.e. if stuff loaded from
  those commands contains an .so, if I understand correctly), we could
  workaround it by setting it to /tmp/secure-dir-XX/ until
  setuptools upstream fixes this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1192966/+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 1194540] Re: It should be possible to remove Swift Accounts after their tenants have been deleted

2015-07-06 Thread John Dickinson
This is normally handled by utilization/billing tools that walk the
drives to see what's there and report on usage in the cluster.

** Changed in: swift
   Status: New = Won't Fix

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

Title:
  It should be possible to remove Swift Accounts after their tenants
  have been deleted

Status in OpenStack Identity (Keystone):
  Invalid
Status in OpenStack Object Storage (Swift):
  Won't Fix

Bug description:
  Consider the following scenario:
  Create a tenant, create a user, create a directory, upload a file, delete the 
user, delete the tenant.

  Now it makes sense to send DELETE to the swift account before deleting the 
tenant.
  However, one might forget it or an application error could occur.

  So it could be imaginable that there are Swift Accounts whose tenants are 
gone and nobody remembers their tenant id.
  In this case all related data in swift is inaccessible.

  This should not be possible.

  Possible solutions:
  a) Make it possible to retrieve a list of swift accounts - A script could be 
used to compare with keystone tenants and check for orphan swift accounts.

  b) Create a keystone callback / hook that notifies Swift to mark accounts as 
deleted once their corresponding keystone tenants have been deleted.
  This feature should be optional so that swift operators can either activate 
or deactivate it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1194540/+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 1190226] Re: Raw SQL used in swift/swift/common/db.py could be escaped

2015-06-06 Thread John Dickinson
** Changed in: swift
   Status: Confirmed = 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/1190226

Title:
  Raw SQL used in swift/swift/common/db.py could be escaped

Status in OpenStack Compute (Nova):
  Invalid
Status in OpenStack Object Storage (Swift):
  Invalid

Bug description:
  Grant Murphy (gmur...@redhat.com) conducted an audit of OpenStack and
  reported the following potential SQL injection vulnerabilities in
  Swift and Nova. These may well not be exploitable, we need to
  doublecheck them.

  swift/swift/common/db.py:376: UPDATE %s_stat SET id=?
  swift/swift/common/db.py:379: SELECT ROWID FROM %s ORDER BY ROWID DESC LIMIT 1
  swift/swift/common/db.py:403: UPDATE %s_stat SET created_at=MIN(?, 
created_at),
  swift/swift/common/db.py:424: SELECT * FROM %s WHERE ROWID  ? ...
  swift/swift/common/db.py:440: SELECT sync_point FROM %s_sync WHERE 
remote_id=?
  swift/swift/common/db.py:456: SELECT remote_id, sync_point FROM %s_sync
  swift/swift/common/db.py:512: INSERT INTO %s_sync (sync_point, remote_id)
  swift/swift/common/db.py:518: UPDATE %s_sync SET sync_point=max(?, sync_point)
  swift/swift/common/db.py:561: metadata = conn.execute('SELECT metadata FROM 
%s_stat' %
  swift/swift/common/db.py:592: md = conn.execute('SELECT metadata FROM 
%s_stat' %
  swift/swift/common/db.py:607: conn.execute('UPDATE %s_stat SET metadata = ?' %
  swift/swift/common/db.py:633: md = conn.execute('SELECT metadata FROM 
%s_stat' %
  swift/swift/common/db.py:644: conn.execute('UPDATE %s_stat SET metadata = ?' %

  nova/nova/virt/hyperv/volumeutils.py:78: WHERE TargetName='%s' % target_iqn)
  nova/nova/virt/hyperv/hostutils.py:66: WHERE DeviceID='%s'
  nova/nova/virt/hyperv/basevolumeutils.py:123: Class WHERE TargetName='%s'
  nova/nova/db/sqlalchemy/utils.py:64:return INSERT INTO %s %s % (
  
nova/nova/db/sqlalchemy/migrate_repo/versions/152_change_type_of_deleted_column.py:40:
 return INSERT INTO %s %s % (

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1190226/+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 1458945] Re: Use graduated oslo.policy instead of oslo-incubator code

2015-06-02 Thread John Dickinson
Swift doesn't yet use oslo policy (incubated or library), so this bug
doesn't apply

** Changed in: swift
   Status: New = Invalid

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

Title:
  Use graduated oslo.policy instead of oslo-incubator code

Status in OpenStack Key Management (Barbican):
  New
Status in OpenStack Telemetry (Ceilometer):
  Fix Released
Status in Cinder:
  Confirmed
Status in OpenStack Congress:
  Confirmed
Status in OpenStack Image Registry and Delivery Service (Glance):
  Fix Released
Status in Orchestration API (Heat):
  Fix Committed
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Bare Metal Provisioning Service (Ironic):
  Fix Released
Status in OpenStack Identity (Keystone):
  Fix Released
Status in MagnetoDB - key-value storage service for OpenStack:
  Confirmed
Status in OpenStack Magnum:
  New
Status in Manila:
  New
Status in Mistral:
  Invalid
Status in Murano:
  Confirmed
Status in OpenStack Neutron (virtual network service):
  Confirmed
Status in OpenStack Compute (Nova):
  Confirmed
Status in Rally:
  Invalid
Status in OpenStack Data Processing (Sahara):
  Fix Released
Status in OpenStack Object Storage (Swift):
  Invalid
Status in Openstack Database (Trove):
  Invalid

Bug description:
  The Policy code is now be managed as a library, named oslo.policy.

  If there is a CVE level defect, deploying a fix should require
  deploying a new version of the library, not syncing each individual
  project.

  All the projects in the OpenStack ecosystem that are using the policy
  code from oslo-incubator should use the new library.

To manage notifications about this bug go to:
https://bugs.launchpad.net/barbican/+bug/1458945/+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 1458945] Re: Use graduated oslo.policy instead of oslo-incubator code

2015-06-02 Thread John Dickinson
** No longer affects: swift

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

Title:
  Use graduated oslo.policy instead of oslo-incubator code

Status in OpenStack Key Management (Barbican):
  New
Status in OpenStack Telemetry (Ceilometer):
  Fix Released
Status in Cinder:
  Confirmed
Status in OpenStack Congress:
  New
Status in OpenStack Image Registry and Delivery Service (Glance):
  Fix Released
Status in Orchestration API (Heat):
  Fix Committed
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Bare Metal Provisioning Service (Ironic):
  New
Status in OpenStack Identity (Keystone):
  Fix Released
Status in MagnetoDB - key-value storage service for OpenStack:
  Confirmed
Status in OpenStack Magnum:
  New
Status in Manila:
  New
Status in Mistral:
  Invalid
Status in Murano:
  Confirmed
Status in OpenStack Neutron (virtual network service):
  Confirmed
Status in OpenStack Compute (Nova):
  Confirmed
Status in Rally:
  Invalid
Status in OpenStack Data Processing (Sahara):
  New
Status in Openstack Database (Trove):
  Invalid

Bug description:
  The Policy code is now be managed as a library, named oslo.policy.

  If there is a CVE level defect, deploying a fix should require
  deploying a new version of the library, not syncing each individual
  project.

  All the projects in the OpenStack ecosystem that are using the policy
  code from oslo-incubator should use the new library.

To manage notifications about this bug go to:
https://bugs.launchpad.net/barbican/+bug/1458945/+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 1261775] [NEW] tempest.api.compute.servers.test_server_rescue.ServerRescueTestXML fails

2013-12-17 Thread John Dickinson
Public bug reported:

2013-12-13 23:21:56.661 | 
==
2013-12-13 23:21:56.665 | FAIL: setUpClass 
(tempest.api.compute.servers.test_server_rescue.ServerRescueTestXML)
2013-12-13 23:21:56.696 | setUpClass 
(tempest.api.compute.servers.test_server_rescue.ServerRescueTestXML)
2013-12-13 23:21:56.697 | 
--
2013-12-13 23:21:56.698 | _StringException: Traceback (most recent call last):
2013-12-13 23:21:56.698 |   File 
tempest/api/compute/servers/test_server_rescue.py, line 74, in setUpClass
2013-12-13 23:21:56.699 | 
cls.servers_client.wait_for_server_status(cls.rescue_id, 'RESCUE')
2013-12-13 23:21:56.699 |   File 
tempest/services/compute/xml/servers_client.py, line 371, in 
wait_for_server_status
2013-12-13 23:21:56.701 | raise_on_error=raise_on_error)
2013-12-13 23:21:56.701 |   File tempest/common/waiters.py, line 82, in 
wait_for_server_status
2013-12-13 23:21:56.701 | raise exceptions.TimeoutException(message)
2013-12-13 23:21:56.702 | TimeoutException: Request timed out
2013-12-13 23:21:56.702 | Details: Server 9c0b846e-8a1c-43b2-9333-156f4cc43248 
failed to reach RESCUE status within the required time (196 s). Current status: 
ACTIVE.
2013-12-13 23:21:56.702 | 

as seen in http://logs.openstack.org/61/62061/2/check/check-grenade-
dsvm/05f61f8/console.html.gz

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

Title:
  tempest.api.compute.servers.test_server_rescue.ServerRescueTestXML
  fails

Status in OpenStack Compute (Nova):
  New

Bug description:
  2013-12-13 23:21:56.661 | 
==
  2013-12-13 23:21:56.665 | FAIL: setUpClass 
(tempest.api.compute.servers.test_server_rescue.ServerRescueTestXML)
  2013-12-13 23:21:56.696 | setUpClass 
(tempest.api.compute.servers.test_server_rescue.ServerRescueTestXML)
  2013-12-13 23:21:56.697 | 
--
  2013-12-13 23:21:56.698 | _StringException: Traceback (most recent call last):
  2013-12-13 23:21:56.698 |   File 
tempest/api/compute/servers/test_server_rescue.py, line 74, in setUpClass
  2013-12-13 23:21:56.699 | 
cls.servers_client.wait_for_server_status(cls.rescue_id, 'RESCUE')
  2013-12-13 23:21:56.699 |   File 
tempest/services/compute/xml/servers_client.py, line 371, in 
wait_for_server_status
  2013-12-13 23:21:56.701 | raise_on_error=raise_on_error)
  2013-12-13 23:21:56.701 |   File tempest/common/waiters.py, line 82, in 
wait_for_server_status
  2013-12-13 23:21:56.701 | raise exceptions.TimeoutException(message)
  2013-12-13 23:21:56.702 | TimeoutException: Request timed out
  2013-12-13 23:21:56.702 | Details: Server 
9c0b846e-8a1c-43b2-9333-156f4cc43248 failed to reach RESCUE status within the 
required time (196 s). Current status: ACTIVE.
  2013-12-13 23:21:56.702 | 

  as seen in http://logs.openstack.org/61/62061/2/check/check-grenade-
  dsvm/05f61f8/console.html.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1261775/+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 1261581] [NEW] tempest.api.compute.v3.images.test_images.ImagesV3TestXML.test_create_image_from_stopped_server fails

2013-12-16 Thread John Dickinson
Public bug reported:

tempest.api.compute.v3.images.test_images.ImagesV3TestXML.test_create_image_from_stopped_server
fails with the following message:

(logs from http://logs.openstack.org/25/62425/1/gate/gate-tempest-dsvm-
full/d606295/console.html)

2013-12-16 23:21:26.365 | Traceback (most recent call last):
2013-12-16 23:21:26.365 |   File 
tempest/api/compute/v3/images/test_images.py, line 91, in 
test_create_image_from_stopped_server
2013-12-16 23:21:26.365 | wait_until='active')
2013-12-16 23:21:26.365 |   File tempest/api/compute/base.py, line 279, in 
create_image_from_server
2013-12-16 23:21:26.365 | server_id, name)
2013-12-16 23:21:26.365 |   File 
tempest/services/compute/v3/xml/servers_client.py, line 515, in create_image
2013-12-16 23:21:26.366 | str(Document(post_body)), self.headers)
2013-12-16 23:21:26.366 |   File tempest/common/rest_client.py, line 302, in 
post
2013-12-16 23:21:26.366 | return self.request('POST', url, headers, body)
2013-12-16 23:21:26.366 |   File tempest/common/rest_client.py, line 436, in 
request
2013-12-16 23:21:26.366 | resp, resp_body)
2013-12-16 23:21:26.366 |   File tempest/common/rest_client.py, line 491, in 
_error_checker
2013-12-16 23:21:26.366 | raise exceptions.Conflict(resp_body)
2013-12-16 23:21:26.367 | Conflict: An object with that identifier already 
exists
2013-12-16 23:21:26.367 | Details: {'message': Cannot 'create_image' while 
instance is in task_state powering-off, 'code': '409'}

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

Title:
  
tempest.api.compute.v3.images.test_images.ImagesV3TestXML.test_create_image_from_stopped_server
  fails

Status in OpenStack Compute (Nova):
  New

Bug description:
  
tempest.api.compute.v3.images.test_images.ImagesV3TestXML.test_create_image_from_stopped_server
  fails with the following message:

  (logs from http://logs.openstack.org/25/62425/1/gate/gate-tempest-
  dsvm-full/d606295/console.html)

  2013-12-16 23:21:26.365 | Traceback (most recent call last):
  2013-12-16 23:21:26.365 |   File 
tempest/api/compute/v3/images/test_images.py, line 91, in 
test_create_image_from_stopped_server
  2013-12-16 23:21:26.365 | wait_until='active')
  2013-12-16 23:21:26.365 |   File tempest/api/compute/base.py, line 279, in 
create_image_from_server
  2013-12-16 23:21:26.365 | server_id, name)
  2013-12-16 23:21:26.365 |   File 
tempest/services/compute/v3/xml/servers_client.py, line 515, in create_image
  2013-12-16 23:21:26.366 | str(Document(post_body)), self.headers)
  2013-12-16 23:21:26.366 |   File tempest/common/rest_client.py, line 302, 
in post
  2013-12-16 23:21:26.366 | return self.request('POST', url, headers, body)
  2013-12-16 23:21:26.366 |   File tempest/common/rest_client.py, line 436, 
in request
  2013-12-16 23:21:26.366 | resp, resp_body)
  2013-12-16 23:21:26.366 |   File tempest/common/rest_client.py, line 491, 
in _error_checker
  2013-12-16 23:21:26.366 | raise exceptions.Conflict(resp_body)
  2013-12-16 23:21:26.367 | Conflict: An object with that identifier already 
exists
  2013-12-16 23:21:26.367 | Details: {'message': Cannot 'create_image' while 
instance is in task_state powering-off, 'code': '409'}

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