OpenStack Image Registry and Delivery Service (Glance)

Glance API should not start if default store cannot be used

Reported by Brian Waldon on 2011-09-17
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Glance
Low
Eoghan Glynn

Bug Description

For example, if glance is configured to use swift as the default store, it should fail to start if the package cannot be imported. Currently the ImportError is ignored and a NameError on 'swift_client' will be thrown later in the upload process.

Jay Pipes (jaypipes) on 2011-10-15
Changed in glance:
status: New → Triaged
importance: Undecided → Low
milestone: none → essex-2
Jay Pipes (jaypipes) on 2011-12-06
Changed in glance:
milestone: essex-2 → essex-3
Eoghan Glynn (eglynn) wrote :

Just thinking about the asymmetry involved in being less tolerant of the default store being unsupported, as opposed to an excplicitly client-selected store being missing.

Contrast these scenarions:

(a) where the default store is unavailable, but all the incoming POST /images calls happen to have X-Image-Meta-Store header set to stores that *are* supported.

(b) the opposite situation, where the default store is available, but the explicitly client-selected stores (via the X-Image-Meta-Store header) are unsupported.

As things currently stand, the glance service is in a position to do useful work under scenario (a), despite the misconfiguration of the default_store. The proposed change would prevent glance even starting up in that case.

Whereas under the existing and proposed new logic, glance would not be in a position to do any useful work in scenario (b), but would still start up successfully (as there is no way of predicting a priori what X-Image-Meta-Store headers clients are going to send).

Perhaps scenario (a) is unrealistically artificial, and it is worth identifying the misconfiguration immediately by failing fast when the default store can't be imported.

Changed in glance:
assignee: nobody → Eoghan Glynn (eglynn)

On Sun, Jan 22, 2012 at 11:46 AM, Eoghan Glynn
<email address hidden> wrote:
> Contrast these scenarions:
>
> (a) where the default store is unavailable, but all the incoming POST
> /images calls happen to have X-Image-Meta-Store header set to stores
> that *are* supported.

I actually think this is a pretty unlikely scenario.

> (b) the opposite situation, where the default store is available, but
> the explicitly client-selected stores (via the X-Image-Meta-Store
> header) are unsupported.

This is a much more likely scenario.

I believe a "fail-fast" solution is the best strategy here, and if the
default store does not function properly, Glance should fail to start.
That way, administrators are forced to deal with the root cause of the
default store not being able to start up.

Cheers!
-jay

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

Changed in glance:
status: Triaged → In Progress

Reviewed: https://review.openstack.org/3297
Committed: http://github.com/openstack/glance/commit/601fb310ef7802a059a375b978e82eb31efafe68
Submitter: Jenkins
Branch: master

commit 601fb310ef7802a059a375b978e82eb31efafe68
Author: Eoghan Glynn <email address hidden>
Date: Mon Jan 23 09:55:06 2012 +0000

    glance-api fails fast if default store unsupported

    Fixes bug 852850

    Ensure the glance API server will not start if the class supporting
    the configured default store cannot be imported.

    Change-Id: I80a97dbc0af4737dbbc1bf0491e7cef222ec3454

Changed in glance:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2012-01-25
Changed in glance:
status: Fix Committed → Fix Released

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

Changed in glance:
status: Fix Released → In Progress

Reviewed: https://review.openstack.org/3525
Committed: http://github.com/openstack/glance/commit/2ce78382004a567defe98d8ccd196277a7cb66ed
Submitter: Jenkins
Branch: master

commit 2ce78382004a567defe98d8ccd196277a7cb66ed
Author: Eoghan Glynn <email address hidden>
Date: Sat Jan 28 16:39:06 2012 +0000

    Restore inadvertantly dropped lines.

    Fixes bug 852850

    Restore two lines inadvertantly dropped when rebasing after a
    merge conflict at patch set 3 in the following review:

      https://review.openstack.org/#change,3297,patchset=3

    Also improve the test case that should have caught this.

    Change-Id: I982b70ee157c19e7aeb7502b7173d8b0fc8c82a1

Changed in glance:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2012-02-27
Changed in glance:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2012-04-05
Changed in glance:
milestone: essex-3 → 2012.1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers