Network and Compute v2 find_extension Broken

[Terry Howe]

Seems like network and compute v2 find_extension are broken. I get dups when there is one with both of them.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/214753
Committed: https://git.openstack.org/cgit/stackforge/python-openstacksdk/commit/?id=44feb9307a3ba8d5414a5333e461842d55b3c7e0
Submitter: Jenkins
Branch: master

commit 44feb9307a3ba8d5414a5333e461842d55b3c7e0
Author: Brian Curtin <email address hidden>
Date: Wed Aug 19 13:41:15 2015 -0500

    Fix find_extension for Network and Compute proxies

    The Extension resource for both Network and Compute were missing two
    pieces that would help their find_extension methods work: for one, the
    `alias` is actually the ID of an extension, and no ID value was set. If
    we knew what the ID was, we could find it (or not find it) directly.
    Before that can even be done, we would need to be able to get it by ID,
    and we didn't have allow_retrieve set on either of those resources.
    Allowing Extension resources to be retrieved by ID causes them to now be
    found.

    Closes-Bug: 1456317
    Change-Id: Id2a2071e9649edca78b2a5455a27e45443d6e8c9

[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