Listing images with the created_at and updated_at filters fails if an operator is not specified

Bug #1584415 reported by Castulo J. Martinez
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Glance
New
Undecided
Unassigned
Mitaka
New
Undecided
Unassigned
Newton
In Progress
Medium
Castulo J. Martinez

Bug Description

When listing images there are several optional parameters that can be used to filter the list of images retrieved by the API. All those optional parameters are documented in the API guide: http://developer.openstack.org/api-ref-image-v2.html#listImages-v2. The following two parameters are not working properly when used, the created_at and the updated_at.

Before the Mitaka release a user could filter the list of images by using the following options:

GET /v2/images?created_at=<Some date time value>
GET /v2/images?updated_at=<Some date time value>

Starting on the Mitaka release users can also use an operator (eq, neq, lt, lte, gt, gte) for comparison purposes when filtering images using the created_at or updated_at parameters. Something like:

GET /v2/images?created_at=<some operator>:<Some date time value>
GET /v2/images?updated_at=<some operator>:<Some date time value>

The problem is that starting on Mitaka, if the user tries to filter the list of images by created_at and updated_at without using an operator the API errors and fails to retrieve the list of images. This means that the API is not backward compatible with Liberty for this operation.

The glance API should be able to work with backward compatibility with Liberty when listing images using the created_at or updated_at filters.

Steps to recreate:

1) Using an environment with the Liberty release, try listing images using the created_at parameter (filter). Example: GET http://my_env:9292/v2/images?created_at=2016-05-20T20:53:15Z

Results: A list containing one image is successfully retrieved.

2) Using an environment with the Mitaka release try the same operation: GET http://my_env:9292/v2/images?created_at=2016-05-20T20:53:15Z

Results: The API returns an error: 400 Bad Request . Bad "created_at" query filter format. Use ISO 8601 DateTime notation.

The same API call should be consistent in both releases.

Changed in glance:
assignee: nobody → Castulo J. Martinez (castulo-martinez)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to glance (master)

Fix proposed to branch: master
Review: https://review.openstack.org/319682

Changed in glance:
status: New → In Progress
Changed in glance:
importance: Undecided → Medium
Revision history for this message
Sabari Murugesan (smurugesan) wrote :

A similar issue can also be seen if you try to filter by the image name that contains a ':' (semicolon)

e.g glance --os-image-api-version 2 image-list --property-filter name=ubuntu:12.04
400 Bad Request
Unable to filter by unknown operator 'ubuntu'.

The root cause is the same and we need to fix the issue for all such cases.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to glance (master)

Reviewed: https://review.openstack.org/319682
Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=bb89dd91fad4b55ca51e4afe4a91634371370bd1
Submitter: Jenkins
Branch: master

commit bb89dd91fad4b55ca51e4afe4a91634371370bd1
Author: Castulo J. Martinez <email address hidden>
Date: Sat May 21 21:21:11 2016 -0700

    Fixes the use of dates when listing images

    When listing images there are several optional parameters that
    can be used to filter the list of images retrieved by the API. The
    following two parameters are not working properly: the created_at and
    the updated_at. Before the Mitaka release it was possible to use these
    filters just using a datetime in the format ISO 8601, starting on
    Mitaka, you need to add an operator along with the datetime stamp or
    the API call fails. This commit adds backwards compatibility so it is
    possible to filter the images list using only a datetime stamp without
    also specifing an operator. If no operator is used an eq operator is
    assumed.

    Change-Id: Id5d5455e77637e0dc7baec25c8163b21634d72c4
    Partial-Bug: 1584415

Revision history for this message
Castulo J. Martinez (castulo-martinez) wrote :

Looks like the submitted patch doesn't fix the problem when the backend DB is PostgreSQL.
I reported this and a similar issue in this related bug: https://bugs.launchpad.net/glance/+bug/1588007

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.