GET /v2/images and /v2/images/XXX does not decrypt image location

[Brian Waldon]

If a deployment is using the metadata_encryption_key, then the image location is encrypted in the database. Since we talk directly to the db from the v2 API, we need to make sure that we're decrypting the image location when we present it to the user. The v1 API depends on the registry to do this.

[Brian Waldon (bcwaldon)]

I discovered this bug initially by creating an image through the v1 API and viewing it through v2. The v2 API will not encrypt the location in addition to the lack of decryption.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/23725
Committed: http://github.com/openstack/glance/commit/a7effe6dc2b8915217675f48a887550b723c1036
Submitter: Jenkins
Branch: master

commit a7effe6dc2b8915217675f48a887550b723c1036
Author: Mark J. Washenberger <email address hidden>
Date: Wed Mar 6 11:26:57 2013 -0800

    Honor metadata_encryption_key in glance domain

    Since v2 is not using the registry client, it was not properly
    encrypting image locations before storing them in the database. With
    this change, the db layer in the glance domain now uses the metadata
    encryption key as well.

    To make this work, the declaration of the metadata_encryption_key option
    had to move to glance.common.config to avoid circular module
    dependencies.

    Fixes bug 1128650

    Change-Id: I3bb5da92ffda7bfe1bc064d11da8ecd4e6d9ab1d