Allow_versions config option in Container-server is deprecated but removing can lead to some version containers failing to version objects

[Matthew Oliver]

This was already known, and we are very slow to actually remove an option that has been deprecated. However, some patches have risen in some of our (SUSE) deployment tools when people removing this option because it's logging at deprecated.

With this option disabled (false) or missing, the container server wont look for the 'x-versions-location' key in the broker metadata, meaning it wont be put into the container_info as 'versions'.

If a container exists with versioning enabled in a cluster pre-kilo (< 2.4.0) and versioning was never "re-enabled" (X-Versions-Location or X-History-Location wasn't sent to the container since 2.4.0+). Then removing this option on the container server will result in this container failing to version objects. I.E it won't backup versions of an object on PUT or replace with old versions on DELETE.

This wont effect any newer Swift cluster that started at version > 2.3.0.

Possible fixes:

 - Write a tool (link the relinker or and auditwatcher) that will go update the container metadata to use the newer SYSMETA versions key (if it doesn't exist).

  - Always return versions/x-versions-location metadata if found in the container, and as the code currently stands it will check for this as a fall back (if the SYSMETA version key isn't found in container metadata).

The first seems overkill and annoyting. But the latter means we need to live with the code in our tree forever or until we mark a swift snapshot data point for upgrades.

[Matthew Oliver (matt-0)]

Here is a simple fix version: http://paste.openstack.org/show/741004/

This just always adds it to the saved_headers. So if it exists it'll always appear in the container_info['verions'].

As it currently stands however, disabling versioning wont disable the legacy versioning. This is also really deprecating the option though, as we just always enable it.

Not saying this is the best approach. But is definitely the simplest. And could be back ported so people could remove the deprecated option, as the middleware would find it.

[Matthew Oliver (matt-0)]

Another option is this: http://paste.openstack.org/show/741005/

This is a little more complecated but in essence if an X-Verrsions-Location metadata key is found in container metadata (legacy metadata key) and the new sysmeta versions-location metadata key is not found, return the legacy value under the new key.

This allows us to pretty much deprecate the old versions location code (minus the above) from the code base, because the middleware will always get the versions-location from container-info sysmeta.

This also means _all_ versioning can be disabled (legacy and new) via the `allow_versioned_writes` versioned_writes middleware option.

[Matthew Oliver (matt-0)]

I'm sure there are other options as well. To fix the bug we could do a combination. Start with the the simple fix that could be backported so people who _have_ already removed it and may not have updated versioning on these old containers, everything still works. and the second can be the actual deprecation, which we could include in the next swift release?

Obviously, in any case, I'll like to also come up with a test to try and demonstrate this bug. Probe test? Anyway, that's a future Matt problem :P