Upgrade fails with HTTP 404
13 views
Skip to first unread message
Viktor Szépe
Jun 24, 2020, 3:16:04 PM6/24/20
to s3ql
Hello!
OVH switched from Keystone v2 to Keystone v3 so I had to update S3QL.
The `s3qladm upgrade` command fails at a certain percentage. Tried several times, it fails at exactly the same percentage.
File "/opt/pyenv/versions/3.7.7/lib/python3.7/site-packages/s3ql/backends/swift.py", line 267, in _do_request
raise HTTPError(resp.status, resp.reason, resp.headers)
s3ql.backends.s3c.HTTPError: 404 Not Found
raise HTTPError(resp.status, resp.reason, resp.headers)
s3ql.backends.s3c.HTTPError: 404 Not Found
What could I do? It is half-upgraded, none of the fsck command versions run on this backup.
Please help me! :)
Thank you.
Viktor Szépe
Jun 24, 2020, 3:51:58 PM6/24/20
to s3ql
On a development server I've tried to delete the filesystem.
`s3qladm clear` errored:
s3ql.backends.common.NoSuchObject: Backend does not have anything stored under key 's3ql_data_1173241'
Daniel Jagszent
Jun 24, 2020, 7:08:17 PM6/24/20
to s3ql
Hello Viktor,
looks like either OVH has lost that file s3ql_data_1173241 or it somehow
got deleted another way. I think it will be hard to figure out what
happened (i.e. how's fault it is).
If you are willing to delete the filesystem anyways, just use Cyberduck
or a swift CLI to delete all objects in the container (or all objects
with the prefix you might be using in the container).
If you wanted to salvage what is left of this broken filesystem, you
maybe could create a dummy object in place of s3ql_data_1173241 and try
to repair the filesystem. But you would need to repair the filesystem
with the old S3QL version (that does not support Keystone v3) and since
the switch to Keystone v3 is already done according to
http://travaux.ovh.net/?do=details&id=42179 you are out of luck I suppose.
looks like either OVH has lost that file s3ql_data_1173241 or it somehow
got deleted another way. I think it will be hard to figure out what
happened (i.e. how's fault it is).
If you are willing to delete the filesystem anyways, just use Cyberduck
or a swift CLI to delete all objects in the container (or all objects
with the prefix you might be using in the container).
If you wanted to salvage what is left of this broken filesystem, you
maybe could create a dummy object in place of s3ql_data_1173241 and try
to repair the filesystem. But you would need to repair the filesystem
with the old S3QL version (that does not support Keystone v3) and since
the switch to Keystone v3 is already done according to
http://travaux.ovh.net/?do=details&id=42179 you are out of luck I suppose.
Reply all
Reply to author
Forward
0 new messages