v2 API policy checks fail with keystone

[dan wendlandt]

It turns out that all of our unit testing and manual testing of the v2 API seems to have been for the scenario where keystone is not enabled (i.e., keystone middleware is not putting a context into the request environment). The result of this is that all API requests were being handled as admin (this is expected), but that meant that a certain chunk of the policy logic specific to handling non-admin queries was not being exercised, so we failed to uncover that how we were calling it was totally broken.

After looking at the code some more, I also believe that the way the API is currently written, we need to add a tenant_id field to subnet in order to make the existing API code correctly enforce multi-tenancy without adding a special case.

I also found a related bug in db_base_plugin_v2.py around querying models (again, this code was never exercised due to the fact that all queries were admin).

One last thing: it seems like we should also change the tenant-id field for networks/subnets/ports to be read-only after creation, as otherwise the checks we are introducing to make sure that a subnet belongs to the same tenant as the network could be invalidated at a later point.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/9473
Committed: http://github.com/openstack/quantum/commit/7d5db13b915ed1617b18cca6e84393f148e62285
Submitter: Jenkins
Branch: master

commit 7d5db13b915ed1617b18cca6e84393f148e62285
Author: Dan Wendlandt <email address hidden>
Date: Sun Jul 8 12:34:22 2012 -0700

    Fix v2 API policy checks when keystone is in use.

    bug 1022032. There were significant errors in how
    the policy framework was being invoked, but existing
    tests did now show them, since they always invoked the
    API with no keystone context. This patch fixes those
    issues and add a significant amount of test coverage
    simulating API calls with keystone enabled.

    As part of this patch, we also needed to add a tenant-id
    attribute to the subnet object. Furthermore, we
    changed the API validation code to prevent tenant-id from
    being changed with a PUT, since changing it after creation
    could invalidate some of the create checks we're planning
    on adding (e.g., that a port is being created on a network
    owned by the same tenant).

    Change-Id: I6da61f0d4ac3b259aa0afcd42cfa8e6ec1a9b035