Releases 0.1.11 and 0.1.12 are not backwards compatible and may cause data loss

[Stuart McLaren]

With glance_store 0.1.10 glance-api.conf may have the following entry:

 [DEFAULT]
 default_store = swift

(ie not specified in the [glance_store] stanza)

A newly created image will have a 'swift' location such as:

 | 3 | 59a06ad2-61ee-4f3e-89cb-6db5204bec1d | swift+http://service%3Aglance- swift:hpinvent@10.0.0.29:5000/v2.0/glance/59a06ad2-61ee-4f3e-89cb-6db5204bec1d | 2015-02-27 10:25:00 | 2015-02-27 10:25:00 | NULL | 0 | {} | active |

If you update to either glance_store 0.1.11 or glance_store 0.1.12
with the same config:

 [DEFAULT]
 default_store = swift

and create a new image, that image will have a 'file' style location:

mysql> select * from image_locations;

| 8 | e39ab820-51d5-4597-a6c4-fb3a24544081 | file:///opt/stack/data/glance/images/e39ab820-51d5-4597-a6c4-fb3a24544081 | 2015-03-04 10:51:38 | 2015-03-04 10:51:38 | NULL | 0 | {} | active |

This behaviour is problematic for a couple of reasons:

1) It violates the principle of least surprise

I haven't changed my config: isn't it reasonably to assume that I won't suddenly (and silently) start saving images somewhere else?

2) It fails silently

It would be easy to detect that someone is using the deprecated option and is about to get unexpected behaviour. Instead we carry on regardless.

3) Anyone deploying the new store will not see any problems in their internal gate

If your gate (ie jobs run to test code before it is merged) runs on a single node (likely) then you will see successful image upload/download behaviour and will not realise that the image is not stored in swift as expected.

4) Every single existing glance deployment will set the default_store parameter

To me it seems reasonable to assume that deprecating this parameter will catch out a significant number of users -- leading images to be stored on local filesystem, unpredictable behaviour, and, potentially, data loss. Considering the cost/benefit of deprecating this parameter I feel there is a strong case for not deprecating it/re-instating it.

[Louis Taylor (kragniz)]

An alternative is to raise an error if [DEFAULT]/default_store is defined.

[Sabari Murugesan (smurugesan)]

+ 1 to kragniz' suggestion.

[Flavio Percoco (flaper87)]

Marking as Won't Fix. We're already at version 0.9 and this sounds like an obsolete bug