Query on swift Upgrade path

Asked by Netmagic Solutions

Hi,

We need to upgrade swift version on our production setup. Before that we need more clarity on below points :

1) What is the upgrade path for version 1.5.0 to 1.8.0 (as far as I have read online, I assume it is 1.5.0-->1.6.0-->1.7.0-->1.8.0).
is the above path right? is there a documentation available for the same ? Can we jump the version from 1.5.0 to 1.8.0 seamlessly?

2) Since we are using swauth, we need to know which version of swauh supports which versions of swift.

3) Do we loose data from the cluster if we delete the existing ring and recreate the ones with the new format ?

Regards,

Viral

Question information

Language:
English Edit question
Status:
Solved
For:
OpenStack Object Storage (swift) Edit question
Assignee:
No assignee Edit question
Solved by:
John Dickinson
Solved:
Last query:
Last reply:
Revision history for this message
Netmagic Solutions (simplidrive) said :
#1

Hi,

With help from John Dickinson, below is the upgrade path I followed :

1) Upgrade storage nodes from 1.5.0 to 1.6.0 (Wait atleast 30 minutes after upgrading a storage node)
2) Upgrade proxy-node from 1.5.0 to 1.6.0
3) Upgrade storage nodes from 1.6.0 to 1.7.4
4) Upgrade proxy-node from 1.6.0 to 1.7.4
5) After successfully testing operations of the setup, upgrade swauth from 1.0.5 to 1.0.6
6) After successfullt testing operations of the setup, proceed to below steps on proxy server for bringing the ring files to the new JSON format.
swift-ring-builder account.builder write_ring
swift-ring-builder container.builder write_ring
swift-ring-builder object.builder write_ring
6) Upgrade storage nodes from 1.7.4 to 1.8.0 (Wait atleast 30 minutes after upgrading a storage node)
7) Upgrade proxy-node from 1.7.4 to 1.8.0
8) Upgrade storage nodes from 1.7.4 to 1.8.0
9) Upgrade proxy-node from 1.7.4 to 1.8.0
10) After successfully testing operations of the setup, upgrade swauth from 1.0.6 to 1.0.9

Note : Please keep updating the configuration files with each upgrade. The sample files are available with the tar.gz of the swift package.

Now, upon upgrading to 1.8.0, if we comment out "swift_hash_path_prefix" from the swift.conf file, the only we are able to access the data. If we uncomment it, we do not see the old data (accounts, containers and objects).

We also read on https://review.openstack.org/gitweb?p=openstack%2Fswift.git;a=commitdiff;h=4a59031539588f5ed64b2c64dbd10d6462e647d7 that the value for "swift_hash_path_prefix" should be left blank if it is an upgrade, which is working file. We uncommented the same and the data is accessible now.

What exactly is the best practice for "swift_hash_path_prefix"? Shall we keep it blank only or anything else should be done with it ?

Regards,

Viral Patadiya

Revision history for this message
John Dickinson (notmyname) said :
#2

I'm not sure from your description if you see your data when the config value is uncommented and blank or when the config value is commented. Both should be effectively the same (if not, that may be a bug).

Since swift_hash_path_prefix is newer than the data in your cluster, you should keep it blank.

Revision history for this message
Netmagic Solutions (simplidrive) said :
#3

Ok,

I only see my data in below cases;
1. swift_hash_path_prefix is commented
2. swift_hash_path_prefix uncommented but with empty string

Anyways, keeping empty value worked for us. I will keep it that way only.

Another query I have is, we have an old swift cluster having swift_hash_path_prefix with blank value, and another new cluster we are building new, which will have a value in swift_hash_path_prefix. Will there be any issue in container-sync where both clusters will communicate?

Regards,

Viral

Revision history for this message
Best John Dickinson (notmyname) said :
#4

No. container-sync will not be affected by differences in swift_hash_path_prefix (or swift_hash_path_suffix either, for that matter).

Revision history for this message
Netmagic Solutions (simplidrive) said :
#5

Thanks John Dickinson, that solved my question.