Crash in quantumapi if neither port or network are not specified in request

[Dan Smith]

Previously may not have been poke-able, but with the interface attachments support recently added, you can get this by doing "nova attach foo". Trace from nova-compute is: http://paste.openstack.org/show/32231/

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/22609
Committed: http://github.com/openstack/nova/commit/cdf5e432de2cf1c0c5466470a6a0bccf999fcdd4
Submitter: Jenkins
Branch: master

commit cdf5e432de2cf1c0c5466470a6a0bccf999fcdd4
Author: Dan Smith <email address hidden>
Date: Thu Feb 21 13:15:23 2013 -0500

    Fix crash in quantumapi if no network or port id is specified

    The existing code assumes that if no port id or fixed ip was specified,
    that the network id passed in is valid. This is not necessarily the case,
    and results in adding None to the list of network ids, which later
    causes a check to see if the network id list is empty to fail.

    This only adds the network id to the list if it was specified, and
    adds a more explicit check to the region that previously fell through
    without finding a matching network so that a similar case would be
    easier to debug in the future.

    Addresses bug #1131264

    Change-Id: I7a8aaea5772707b8bd6313249e74b1302eedefe8

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/22610
Committed: http://github.com/openstack/nova/commit/394c693e359ed4f19cc2f7d975b1f9ee5500b7f6
Submitter: Jenkins
Branch: master

commit 394c693e359ed4f19cc2f7d975b1f9ee5500b7f6
Author: Dan Smith <email address hidden>
Date: Thu Feb 21 15:09:29 2013 -0500

    Make allocate_for_instance() return only info about ports allocated

    Previously, the compute manager was filtering the results based on the
    port id that the user requested. However, if they do not pass one (which
    is valid) then we can not do the filter and we fail. This makes the
    allocation function do the filtering, which should not affect the normal
    use case where it is only called once, since all the ports returned were
    allocated at that time.

    The manager filter behavior is thus removed and a test is added to
    verify that the allocate method does the right thing the second time
    around.

    This fixes the fallout found after fixing the actual cause of bug 1131264

    Change-Id: I8f3af96051268503596007491af365e8ce28f5b3