Trusts expires_at field is rounded down, doesn't match docs

[Steven Hardy]

The API docs[1] state:

"expires_at (string, ISO 8601 extended format date time with microseconds)"

and in the examples:

"expires_at": "2013-02-27T18:30:59.999999Z"

However this doesn't match the actual behaviour of the API, which rounds down the microseconds component. Rounding down seems perfectly reasonable, but we should probably modify the docs to match, if this is correct behaviour:

Creating a trust with this post body:

{
    "trust": {
        "expires_at": "2013-10-30T16:47:57.964539Z",
        "impersonation": true,
        "project_id": "b5d498f9631244b59912ce2a0025cf8d",
        "roles": [
            {
                "name": "Member"
            }
        ],
        "trustee_user_id": "f55efd1d617e4367891d202a811d7728",
        "trustor_user_id": "c46925e946c24683bd29143851525f7d"
    }
}

Results in a trust which looks like this:
{
    "trust": {
        "expires_at": "2013-10-30T16:47:57.000000Z",
        "id": "f2588d87f82d4e539db0bd06e5a0a2ab",
        "impersonation": true,
        "links": {
            "self": "http://127.0.0.1:5000/v3/OS-TRUST/trusts/f2588d87f82d4e539db0bd06e5a0a2ab"
        },
        "project_id": "b5d498f9631244b59912ce2a0025cf8d",
        "roles": [
            {
                "id": "fb2876a05f724d3e8fe0f562e8737a50",
                "links": {
                    "self": "http://127.0.0.1:5000/v3/roles/fb2876a05f724d3e8fe0f562e8737a50"
                },
                "name": "Member"
            }
        ],
        "roles_links": {
            "next": null,
            "previous": null,
            "self": "http://127.0.0.1:5000/v3/OS-TRUST/trusts/f2588d87f82d4e539db0bd06e5a0a2ab/roles"
        },
        "trustee_user_id": "f55efd1d617e4367891d202a811d7728",
        "trustor_user_id": "c46925e946c24683bd29143851525f7d"
    }
}

[1] https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-trust-ext.md

[Steven Hardy (shardy)]

Actually, it seems the response from the POST to create the trust is not rounded, but subsequent GET's to retrieve the trust are.

[Steven Hardy (shardy)]

Note there is some evidence of the issue here in the trusts tempest test results which I'm developing. Oddly the test fails with and without setting the subsecond component to 000000..

Not had time to dig into it yet, but it may be that this truncation is not happening in every case. See the test logs related to patchests 2 and 3 here:

https://review.openstack.org/#/c/54810/

[Steven Hardy (shardy)]

Actually it's probably the get/post difference I mentioned in #1, so I'll just skip the test until this bug is resolved.

[Juan Manuel Ollé (juan-m-olle)]

What I note is that the problem is in MySQL, it doesn't support microsecond in version <5.6, in addition SQLAchemist had worked in this problem and seems to be a fix merged in version 0.8.0 (we are currently using 0.7.x).

http://www.sqlalchemy.org/trac/ticket/2534

Some Proposals to fix this issue are:
- Add an extra column to storage microseconds
- Storage in mySQL the DateTime as an string (like SQLite) and then parse it. (I like this more)

Any suggest?

[Dolph Mathews (dolph)]

Bug in MySQL: http://bugs.mysql.com/bug.php?id=8523

MySQL 5.6.4 (2011-12-20) release notes have more details: https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-4.html

[Juan Manuel Ollé (juan-m-olle)]

Dolph: Do you think we should implement any kind of workaround for previous MySQL version? or we should tag this issue as not an Keystone Bug?

[Dolph Mathews (dolph)]

Unless it's a significant pain point somewhere in the API, I'd personally rather live with this as a known issue until 5.6 is prevalent (it's certainly not today), and note it at the API layer (we don't allow user-defined expiration in too many places; where we do allow it, we can claim that expiration may occur earlier than specified, but never later).

[Steve Martinelli (stevemar)]

unassigning, there really isn't much work for keystone here... as dolph mentioned it'll be fixed with mysql 5.6