Flavors find is broken

[Terry Howe]

Nova does not support filtering for flavors for some reason. The SDK should probably still work for find for flavors.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/156004

[OpenStack Infra (hudson-openstack)]

Change abandoned by Brian Curtin (<email address hidden>) on branch: master
Review: https://review.openstack.org/156004
Reason: Looking at other implementations

[Brian Curtin (brian.curtin)]

Finding by ID works, finding by name somehow doesn't.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/214822
Committed: https://git.openstack.org/cgit/stackforge/python-openstacksdk/commit/?id=201c86c74bc187305cf4a7a205c1794c1890f43e
Submitter: Jenkins
Branch: master

commit 201c86c74bc187305cf4a7a205c1794c1890f43e
Author: Brian Curtin <email address hidden>
Date: Wed Aug 19 17:42:41 2015 -0500

    Make Resource.find more generically applicable

    The previous Resource.find was using query parameters of
    id= and name= after directly attempting Resource.get_by_id.
    In a few cases, this actually works, such as on Server.find
    where it's able to accept the name= query parameter and
    properly return a match. However, most other resources don't
    work with those query parameters, so unless the find was done
    by ID, there was very little chance of finding a match.

    This change keeps mostly the same structure but does so without
    using query parameters. It keeps the original Resource.get_by_id
    to potentially find an immediate match, but if it needs to look
    further it does so by making one request for all data and then
    looks at both the name and id attributes in a loop to find a matching
    resource.

    This refactoring ends up fixing several outstanding bugs for
    certain resources' find methods not working. It additionally
    fixes a bug where searches by name would raise DuplicateResource
    both when a single match existed, duplicate matches existed,
    and also when no match existed. This was due to the baked in
    query parameter logic and assumption that it was working causing
    us to handle those responses differently than what they were
    really signifying.

    Change-Id: I4ae0599334b73b14a36a6f63bc8b26343abb1466
    Closes-Bug: 1466174
    Closes-Bug: 1384230
    Closes-Bug: 1456317
    Closes-Bug: 1455768
    Closes-Bug: 1486705

[Matthew Edmonds (edmondsw)]

this fix either didn't work or it's been re-broken... I've opened https://bugs.launchpad.net/python-openstacksdk/+bug/1628316 since this is already marked as fix committed.