aggregate db api handles read_deleted in an inconsistent way

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

Reviewed: https://review.openstack.org/5397
Committed: http://github.com/openstack/nova/commit/1cd050e767c4dd5e9a6664911f4f8e408f437f41
Submitter: Jenkins
Branch: master

commit 1cd050e767c4dd5e9a6664911f4f8e408f437f41
Author: John Garbutt <email address hidden>
Date: Tue Mar 20 10:14:58 2012 +0000

    Fixes bug 949038

    Make the api calls better fit the standard pattern where
    read_deleted can be changed using context.read_deleted

    I have retained the ability to pass read_deleted
    explicitly. If that is not specified, it uses the value in
    the context.

    Note: read_deleted defaults to "no" in the context.

    The two exceptions are:
     aggregate_host_get_all
     aggregate_get_all

    In this case, it is better for read_deleted=yes to be the default
    So in this case the context cannot be used, as that would default
    to read_deleted=no. In this case you must explicity override
    read_deleted, the context is totally ignored, as before.

    Change-Id: Idb048a592d8c6b788651d131a3345e70989c0ec4

Fix proposed to branch: milestone-proposed
Review: https://review.openstack.org/5774

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

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

commit ef1f1738f23909feb5c5b2a617b1cb88986989ee
Author: Mark McLoughlin <email address hidden>
Date: Sun Mar 25 21:59:29 2012 +0100

    Clean up read_deleted support in host aggregates code

    tl;dr - this is a cleaner fix for bug #949038

    It seems clear to me that all of the DB APIs should not explicitly pass
    read_deleted='no' or read_deleted='yes' to model_query without good
    reason.

    We want to allow callers to specify read_deleted via the context and
    that only works if we don't explicitly pass it to model_query().

    If we don't explicitly specify it to model_query(), we use the value
    from the context which defaults to 'no'.

    Given all that, there is no need to support read_deleted to any of the
    DB API calls because they should support specifying the flag via the
    context. There should also be no need to pass read_deleted='no' because
    that is the default.

    Really, the only place there should be any mention of read_deleted is
    where we want read_deleted='yes' behaviour e.g.

      - In tests, where we want to check the operational_state of an
        aggregate after it has been deleted

      - Where we want to support undeleting an aggregate or aggreate host

    Change-Id: I916a8d189a33d7f30838cccb26531a024066ef96