[Bug 1582475] Re: Managing access gets HTTP 500 due to using deprecated option timeout

[Chris Johnston]

** Also affects: swauth (Ubuntu Trusty)
   Importance: Undecided
       Status: New

** Also affects: swauth (Ubuntu Wily)
   Importance: Undecided
       Status: New

** Also affects: swauth (Ubuntu Xenial)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1582475

Title:
  Managing access gets HTTP 500 due to using deprecated option timeout

Status in swauth package in Ubuntu:
  In Progress
Status in swauth source package in Trusty:
  In Progress
Status in swauth source package in Wily:
  In Progress
Status in swauth source package in Xenial:
  In Progress

Bug description:
  [Impact]

  When running the 1.0.4-0ubuntu1 version of swauth with Swift
  2.7.0-0ubuntu2~cloud0 (Swift from trusty-mitaka cloud archive) the
  server errors out with an error 500 when creating accounts. This
  prevents users from being able to create or manage accounts using
  swauth against Mitaka.

  root at juju-swauth-machine-1:~# swauth-add-user -A http://127.0.0.1:8080/auth/ -K swauthkey -a test tester testing
  Account creation failed: 500 Server Error
  User creation failed: 500 Server Error

  The upstream Swift release *finally* removed a deprecated timeout
  parameter for their custom memcache client 'set' function call in
  https://review.openstack.org/#/c/257065/ in order to maintain api
  compatible with the official python-memcache client.

  The minimal fix for this bug is to backport commit c44b5b6 [1], which
  adds a test to determine if the version of swift has the time option
  or not. This commit has been removed in the latest version of swauth
  because swift/swauth no longer support clients < Juno, which would
  mean they all have the time parameter rather than the timeout
  parameter. The removal of that code caused this bug to manifest
  itself.

  [1]
  https://github.com/openstack/swauth/commit/c44b5b64489c1721cf05992b14e53b0c8a4e325e

  [Test Case]

  1. Deploy swift-proxy and swift storage from the trusty-liberty Ubuntu Cloud Archive.
  2. Deploy the swauth middleware (apt-get install swauth).
  3. Configure swauth following the instructions at http://swauth.readthedocs.io/en/latest/
  4. Create test user:
       swauth-add-user -A http[s]://<host>:<port>/auth/ -K swauthkey -a test tester testing
  5. Ensure it works:
       swift -A http[s]://<host>:<port>/auth/v1.0 -U test:tester -K testing stat -v

  [Regression Potential]

  The cherry-pick of the fix should be fairly safe as the code dates to
  April 2013. That was, however, on a different version of the swauth
  code. An error in this code path would prevent servers from being able
  to use Swift itself as a wsgi middleware auth plugin.

  [Other Info]

  Upstream version 1.1.0 was recently released (after having been
  defunct since version 1.0.8 for 3 years) with the Mitaka version of
  OpenStack under the big tent model. The 1.1.0 version was recently
  synced from debian unstable into yakkety. There's a fair number of
  changes between 1.0.4 and 1.1.0 that I think warrants more testing and
  verification against the trusty-mitaka cloud-archive. However, the
  minimally invasive patch will enable this to work across versions
  providing sooner relief to any users encountering this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/swauth/+bug/1582475/+subscriptions