datetime objects are serialized into xml using simply str() and this
is a slightly different format from ISO8601 in that the date isn't
separated from the time using 'T'.
(However, note that the iso8601 library happily accepts this format)
Add a specific regexp for this format so we can test for it in the
places we know it is used. This also means we can remove the generic
%(timestamp)s regexp.
Note that unlike the isotime and strtime formats, whether this format
includes timezone or microsecond information depends on whether the
datetime object had those fields set. The isotime format always
includes a timezone but not microseconds, whereas the strtime format
never includes a timezone but always includes microseconds.
There are a small number of examples where this format is used in JSON
too - e.g. the instance usage audit log extension pre-serializes its
timestamps by doing:
return dict(period_beginning=str(begin),
period_ending=str(end),
Using a name like 'xmltime' for the timestamp format used in cases
like this actually makes sense - it highlights that the format used
in this case is a weird mistake.
Full context here:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/033971.html
Change-Id: I70f839ac17273ed10078b833aeba308bd5e994e1
Somehow, the instance actions API was different in three places:
1. The actual API from a running system
2. The regular unit tests
3. The api_samples tests
This fixes the fake_instance_actions module to look like the database
model (which was the root of the problem) as well as the api_samples
and regular unit tests to properly confirm the actual behavior I
validated manually against a running system. This looks like it
changes the external API, but in fact, it makes things match what
the external API actually is.
Change-Id: I0c8ddff3e0819a65667617083dfaa74f7317cc05
Adds a new API extension for accessing the recorded actions and events
on an instance. Usage is documented with api samples.
Additionally it modified the db api to retrieve actions by request_id
since the api does not return the db id. This extension is the first
consumer of that method so there's no issue of changing behaviour
elsewhere.
Blueprint instance-actions
DocImpact
Change-Id: I74109586cc762a7f51d2b114896cf071ee0671cb
Mark McLoughlin