Updated openstack/openstack
Project: openstack/heat  ab5d961efd062662544218f36ae64277d39763fd
null
Catch error deleting trust on stack delete

When deleting a stack, it's possible for deleting the trust to fail,
for example if the user deleting the stack is not the user who created
it, or an admin (which raises a Forbidden error), or due to some
other transient error e.g connection to keystone interrupted.

Currently in this case, we fail to mark the stack deleted in the DB
and leave the status "DELETE, COMPLETE", which is misleading.

Conflicts:
	heat/tests/test_parser.py

Closes-Bug: #1247200
(cherry picked from commit 214ba503757e5bd9bf5a5fab6692c4e94d0536fa)
Change-Id: Ie8e9ea48bc4f44e56ff4764123fcca733f5bd458
Updated openstack/openstack
Project: openstack/glance  1982ca25ec3cb7755e3ea2672dd3140d920a5051
null
Filter out deleted images from storage usage

All database API's currently include deleted images in the calc of
storage usage. This is not an issue when deleted images don't have
locations. However, there are cases where a deleted image has deleted
locations as well and that causes the current algorithm to count those
locations as if they were allocating space.

Besides this bug, it makes sense to not load deleted / killed /
pending_delete images from the database if we're actually not
considering them as valid images.

The patch also filters out deleted locations.

NOTE: In the case of locations, it was not possible to add a test for
the deleted locations because it requires some changes that are not
worth in this patch. In order to mark a location as deleted, it's
necessary to go through the API and use a PATCH operation. Since this is
a database test, it doesn't make much sense to add API calls to it.
Calling the image_destroy function with an empty location list will
remove all the locations which won't help testing that specific case.

I'll work on a better solution for that in a follow-up patch.

DocImpact:

    The patch now excludes deleted images from the count, this fixes a
    bug but changes the existing behaviour.

    The patch excludes images in pending_delete from the count, although
    the space hasn't be freed yet. This may cause the quota to be
    exceeded without raising an error until the image is finally deleted
    from the store.

Conflicts:
	glance/tests/functional/db/test_sqlalchemy.py

Closes-Bug: #1261738
(cherry picked from commit b35728019e0eb89c213eed7bc35a1f062c99dcca)
Change-Id: I82f08a8f522c81541e4f77597c2ba0aeb68556ce