Do not log 14+ INFO lines on a broken pipe error (eventlet)

Under eventlet if the client disconnects while Keystone is trying
to transmit data, approximately 14 lines of traceback are logged.

This could result in massive logs if done repeatedly; worst case
scenario could include a denial of service due to disk space being
exhausted.

Change-Id: Iaf14c64799daa7539d1bd85cb6c6457380c111d9
Closes-Bug: #1334466
Updated from global requirements

Change-Id: I8402f264446d94c43d00ef56fd0eb43a1551d979
Correct the region table to be InnoDB and UTF8

The region table was not specified as being InnoDB or UTF8 under
mysql initially. The migration will fail if the defaults for MySQL
are not set correctly. A new method has been added to the
migration_helpers module to detect and correct the InnoDB / UTF8
specific issue with the region table.

Change-Id: I374c3dd46a4292e8f9e74ef75a8bb463b951f135
Closes-Bug: #1334779
Merge "Updated from global requirements" into stable/icehouse
Updated from global requirements

Change-Id: Ic2c44e1410592d7080af7eb8f6df8f955382393c
Merge "Do not log 14+ INFO lines on a broken pipe error (eventlet)" into stable/icehouse
Merge "Correct the region table to be InnoDB and UTF8" into stable/icehouse
Don't override tox envdir for pep8

infra's run-pep8 job assumes the envdir for pep8 job is not
overwritten, so it can call out to .tox/pep8/bin/pip.

This bug is causing keystone pep8 job to occasionally fail in the gate.

If the motivation behind overriding the envdir jobs to use venv, one can
use devpi and/or wheels to speed up the process of building a venv.

This isn't a backport because in stable/icehouse Keystone didn't set
the venv for the cover job.

Change-Id: I32cd46152caa73e1308fdd216ba016c80a5a9b4f
Closes-Bug: #1352134
Add tests related to V2 token issued_at time changing

There was no test that showed that when a V2 token is used in a V3
context its "issued_at" time changes. This affects validating a V2
token using V3 and also revoking a V2 token. The tests show the
current incorrect behavior.

Partial-Bug: #1348820

Change-Id: I2a3443847b2699384413933ae164fdc183aa110f
(cherry picked from commit 556fb860311675fc437585651e4602b2908451eb)
Fix for V2 token issued_at time changing

When the server converted a V2 token to a V3 token it regenerated
the issued_at time.

This was causing the server to return a different issued_at time
when a V2 token was validated using the V3 API.

This was causing the server to fail to revoke a V2 token if it was
revoked before validating it first because the regenerated token was
considered to be after the revocation event.

Change-Id: I71fea3253295ee8794fb2c8211e1f030de3ae205
Closes-Bug: #1348820
(cherry picked from commit a4c73e4382cb062aa9f30fe1960d5014d3c49cc2)
Correct revocation event test for domain_id

The revocation event test used "user_domain_id" and
"project_domain_id" as token fields that the "domain_id"
revocation event field maps to, but the token fields are
actually "identity_domain_id" and "assignment_domain_id", as
can be seen in
keystone.contrib.revoke.model.build_token_values().

Conflicts:

	keystone/tests/test_revoke.py

Change-Id: I208484da243403287eaa33893d57429c7e6d27c7
Partial-Bug: #1349597
(cherry picked from commit c4447f16da036fe878382ce4e1b05b84bdcc4d4e)
Fix revoking domain-scoped tokens

A token scoped to a domain wouldn't be revoked for a domain-wide
revocation event. This is because the code to convert a token to a
dict for revocation event processing didn't handle domain-scoped
tokens.

Partial-Bug: #1349597

Change-Id: Ib2c58f3fc8790dbe7f8b073d18d3fa9b0dff608d
(cherry picked from commit 3e035ebb726167aef43c4a865c7e7f7d3b0978fb)
Add a test for revoking a scoped token from an unscoped

There was no test that showed that when a scoped token created from
an unscoped token is revoked that the unscoped token also winds up
being revoked.

Change-Id: I2c1574573488bb60a059c5d7f8747d6a1977aab7
Partial-Bug: #1347318
(cherry picked from commit 097b9aa0395e778b40c2028f45cf8d37663e387a)
Fix revoking a scoped token from an unscoped token

When a scoped token that was created from an unscoped token was
revoked, the original token wound up being revoked. This is because
the scope wasn't included in the revocation event. By including the
scope in the revocation event only the scoped token is revoked.

Change-Id: I5652663ab7e1176d3b1efc5d218a8a020498067e
Closes-Bug: #1347318
(cherry picked from commit da00da732d6be0626810fe4ec87d40dab16117de)
Make test_revoke expiry times distinct

Calling _future_time had the possibility of returning the same value
if it is called between clock ticks.  It appears to be happening in
gate, potentially due to being run in a VM.

Instead, for the loop that revokes distinct events,
Assign each a different expires_at time.

Conflicts:

	keystone/tests/test_revoke.py

Change-Id: Iab7ed92bb1e142651265a167ae73d6d1225b01a9
Closes-Bug: #1300581
(cherry picked from commit 5fbb0a28bc40d3e30b416a284cbe63f233cca39e)
Fix revocation event handling with MySQL

When MySQL is used to store revocation events, events are returned
from the database with the timestamps truncated to the second. This
causes a revocation event for a token (which has the issued_at
timestamp to the microsecond) to not match the revocation event and
therefore the token is not considered to be revoked.

The fix is to have the revocation events and token timestamps both
always be truncated to the second. This will cause all tokens for a
user that are issued within a second to be revoked when any of those
tokens are revoked, which shouldn't be a problem.

Conflicts:

	keystone/tests/test_v3_os_revoke.py

Change-Id: Ibd82b4ce910206dfd504c396614ae2ebed025e9b
Closes-Bug: #1347961
(cherry picked from commit 7aee6304f653475a4130dc3e5be602e91481f108)