OpenStack Object Storage (swift)

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

Bug #1811044 reported by Matthew Oliver
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
New
Undecided
Matthew Oliver

Bug Description

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)
Changed in swift:
assignee: nobody → Matthew Oliver (matt-0)
summary: Allow_versions config option in Container-server is deprecated but
- removing can lead to lost object data
+ removing can lead to some version containers failing to version objects
Revision history for this message
Matthew Oliver (matt-0) wrote :

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.

Revision history for this message
Matthew Oliver (matt-0) wrote :

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.

Revision history for this message
Matthew Oliver (matt-0) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.