Unable to create s3ql file system with OpenStack/Swift backend

[Paulo Sacramento]

Dear all,

I have successfully installed S3QL on a CentOS 7 VM and am trying without success to create an S3QL file system using an OpenStack/Swift object storage backend provided by the cloud provider. I am using the mkfs.s3ql command for this. Main references I used: http://www.rath.org/s3ql-docs/mkfs.html , http://www.rath.org/s3ql-docs/backends.html#openstack-swift and https://dmsimard.com/2014/09/29/s3ql-a-filesystem-over-http-with-openstack-swift/.

My ~/.s3ql/authinfo2 file:

[swift]
backend-login: cloud_00506:psacramento
backend-password: *******
storage-url: swiftks://eocloud.eu:5000/regionOne:My_Object_Storage

And the command I'm trying is:

mkfs.s3ql --debug swiftks://eocloud.eu:5000/regionOne:My_Object_Storage

This gives me a "MainThread root.excepthook: No permission to access backend." error. According to the OpenStack GUI made available by the provider, the keystone authentication URL is actually https://eocloud.eu:5000/v3 , but if I change the above URL to this I get a "Invalid storage URL" error instead. I have also tried to change backend-login to "cloud_00506 project_with_eo:psacramento", since one of the reasons for the problem might be the way the login is built from the project/tenant name and user name. No success.

After dozens of unsuccessful attempts trying to get the storage URL and credentials right, I thought about installing the python-swift command-line client (https://docs.openstack.org/python-swiftclient/pike/cli/index.html) to see if I was able to connect to the storage and upload/delete files. This worked well the first time I tried, using the same URLs and credentials I tried with mkfs.s3ql , so I'm sure I have the correct URLs and credentials.

The OpenStack GUI provides a handy feature to download an RC file (say openrc.sh) that you can then use to setup your environment on RedHat/CentOS ("source openrc.sh"). It creates a few environment variables that a client such as python-swift can use for the connection. In any case, I managed to operate correctly using either the environment variables or the command-line parameters, so - again - I'm sure that I have the correct URL and credentials. I suppose the issue is in how S3QL is interpreting or expects either the URL or the credentials.

The openrc.sh file is:

- - - start file - - -

#!/usr/bin/env bash

# To use an OpenStack cloud you need to authenticate against the Identity
# service named keystone, which returns a **Token** and **Service Catalog**.
# The catalog contains the endpoints for all services the user/tenant has
# access to - such as Compute, Image Service, Identity, Object Storage, Block
# Storage, and Networking (code-named nova, glance, keystone, swift,
# cinder, and neutron).
#
# *NOTE*: Using the 3 *Identity API* does not necessarily mean any other
# OpenStack API is version 3. For example, your cloud provider may implement
# Image API v1.1, Block Storage API v2, and Compute API v2.0. OS_AUTH_URL is
# only for the Identity API served through keystone.
export OS_AUTH_URL=https://eocloud.eu:5000/v3

# With the addition of Keystone we have standardized on the term **project**
# as the entity that owns the resources.
export OS_PROJECT_ID=9c041f03a252466087cf38b2be35ff0b
export OS_PROJECT_NAME="cloud_00506 project_with_eo"
export OS_USER_DOMAIN_NAME="cloud_00506"
if [ -z "$OS_USER_DOMAIN_NAME" ]; then unset OS_USER_DOMAIN_NAME; fi

# unset v2.0 items in case set
unset OS_TENANT_ID
unset OS_TENANT_NAME

# In addition to the owning entity (tenant), OpenStack stores the entity
# performing the action as the **user**.
export OS_USERNAME="psacramento"

# With Keystone you pass the keystone password.
echo "Please enter your OpenStack Password: "
read -sr OS_PASSWORD_INPUT
export OS_PASSWORD=$OS_PASSWORD_INPUT

# If your configuration has multiple regions, we set that information here.
# OS_REGION_NAME is optional and only valid in certain environments.
export OS_REGION_NAME="RegionOne"
# Don't leave a blank variable, unset it if it was empty
if [ -z "$OS_REGION_NAME" ]; then unset OS_REGION_NAME; fi

export OS_IDENTITY_API_VERSION="3"

- - - end file - - -

With these environment variables set on the shell, the simple command "swift list" gives me a list of object storage buckets. With a clean environment, the following command gives me the same results:

swift --os-auth-url https://eocloud.eu:5000/v3 --auth-version 3 --os-project-name "cloud_00506 project_with_eo" --os-project-domain-name cloud_00506 --os-username psacramento --os-user-domain-name cloud_00506 --os-password ********* list

Any clue as to what I'm doing wrong with mkfs.s3ql?

Thanks in advance for all help,

Paulo

[Nikolaus Rath]

On Jan 05 2018, Paulo Sacramento <psa...@gmail.com> wrote:
> And the command I'm trying is:
>
> mkfs.s3ql --debug swiftks://eocloud.eu:5000/regionOne:My_Object_Storage
>
> This gives me a "MainThread root.excepthook: No permission to access
> backend." error. According to the OpenStack GUI made available by the
> provider, the keystone authentication URL is actually
> https://eocloud.eu:5000/v3 , but if I change the above URL to this I get a
> "Invalid storage URL" error instead.

With the storage URL above, S3QL will attempt to connect to
https://eocloud.eu:5000/v2.0 (note the different version), which is
probably the source of your problems.

I am not sure how v2.0 differs from v3, and how much work it would be to
support it. Experimentally, you could just try to change v2.0 to v3 in
src/s3ql/backends/swiftks.py and see what happens.

In any case, it would be great if you could file a bug at
https://bitbucket.org/nikratio/s3ql/issues. At the very least, the
documentation should be updated to mention that only v2.0 is supported.

Best,
-Nikolaus

--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

»Time flies like an arrow, fruit flies like a Banana.«

[Daniel Jagszent]

[...]

I am not sure how v2.0 differs from v3, and how much work it would be to
support it. Experimentally, you could just try to change v2.0 to v3 in
src/s3ql/backends/swiftks.py and see what happens.

[...]

That does not work since Keystone 2 and 3 are quite different. Keystone 2 has the concepts of "users" and "tenants" (one tenant can have multiple users) and Keystone 3 has "users" "projects" and "domains". (One domain can have multiple projects and multiple users. users can be part of a project)

AFAIK, with Keystone 3 you also need to do a second request to the service catalog in order to actually get the Swift server URL.

For Keystone 3 support in the swiftks backend having https://bitbucket.org/nikratio/s3ql/issues/202/allow-specifying-backend-options-in would probably be preferable. Then the swiftks backend could have options that would be more natural ("api-version", "user-name", "user-id", "tenant-name", "tenant-id", "project-name", "project-id", "domain-name", "domain-id", "password")

 

[Paulo Sacramento]

Hi Nikolaus, thank you for your reply.
 

With the storage URL above, S3QL will attempt to connect to
https://eocloud.eu:5000/v2.0 (note the different version), which is
probably the source of your problems.

I am not sure how v2.0 differs from v3, and how much work it would be to
support it. Experimentally, you could just try to change v2.0 to v3 in
src/s3ql/backends/swiftks.py and see what happens.

In any case, it would be great if you could file a bug at
https://bitbucket.org/nikratio/s3ql/issues. At the very least, the
documentation should be updated to mention that only v2.0 is supported.

Apparently someone had already run into this (see https://bitbucket.org/nikratio/s3ql/issues/203/add-support-for-keystone-v3-for-swift) and from the thread it even seems someone was implementing v3 support. Maybe it led nowhere?

The page at http://www.rath.org/s3ql-docs/backends.html#openstack-swift does refer to Keystone (v2), I assumed it would work with v3. I've asked my provider if they support other types/versions of authentication, that would also be a quick way forward for me.

I can report a bug, but it's more a duplicate of 203...

Thanks again.