Check for None or timestamp in availability zone api sample

test_availability_zone_detail depends on the services not having an
updated_at time set in the database.  This is set by a periodic task so
it's not guaranteed to be set, or not, shortly after the service starts.
On a fast system the test reliably passes, but adding a delay causes the
test to start failing.  Introducing a time.sleep(5) in the test seems to
make it reliably fail for me.  The test should pass if updated_at is set
to None or a timestamp.

Change-Id: I976ddf5354a52ca06a6419a92abcacb7d2379a37
Closes-bug: 1300810
compute: using format_message() to convert exception to string

We probably need to use format_message when converting a
NovaException to a string.
As well we can remove the cast to unicode of the parameter msg
from the local method notify since this method will only get
message in a string format.

Change-Id: I6fddfb9e124b4096f0ebc3da81c3044b1b24cedf
Avoid the possibility of truncating disk info file

Commit dc8de42 makes nova persist image format to a file to avoid
attacks based on changing it later. However the way it was implemented
leaves a small window of opportunity for the file to be truncated before
it gets written back to effectively making it possible for data to get
lost leaving us with a potential problem next time it is attempted to be
read.

This patch changes the way file is updated to be atomic, thus closing
the race window (and also removes the chown that we did not really
need).

It is worth noting that a better solution to this would be
to allow the code calling the imagebackend to write the file (once!)
and make it impossible to update after the boot process is done. This
approach would require more refactoring of the libvirt driver code, and
may be done in the future.

Partial-bug: #1221190
Change-Id: Ia1b073f38e096989f34d1774a12a1b4151773fc7
Update user_id length to match Keystone schema in volume_usage_cache

Update the maximum length to match the Keystone schema for maximum
user_id length in volume_usage_cache. In the case that Keystone were
to leverage the full varchar 64, there would potentially be data loss
and/or collision of user_ids across records.

This change originates from the conversation about increasing the
length of user_ids in Keystone:

http://lists.openstack.org/pipermail/openstack-dev/2014-February/028125.html

Even with the length not changing, it is important to ensure there is no
loss of data/resolution when relying on user_id to identify users uniquely.

Closes-Bug: #1226171
Change-Id: I05a5644a29d6e2432311c2ee5331970d5e8b0683
Merge "Update user_id length to match Keystone schema in volume_usage_cache"
Merge "Check for None or timestamp in availability zone api sample"
Merge "Avoid the possibility of truncating disk info file"
Merge "compute: using format_message() to convert exception to string"