Docker's SAIO doesn't work

[Some Developer]

My env:

Distributor ID: Ubuntu
Description: Ubuntu 23.04
Release: 23.04
Codename: lunar

Docker version 24.0.6, build ed223bc

Details:

What I'm trying to do is to run SAIO's container, according to docs (https://hub.docker.com/r/openstackswift/saio) it should be as easy as:

docker pull openstackswift/saio
docker run -d -p 8080:8080 openstackswift/saio

Container start and I try to test communication with it:
curl http://127.0.0.1:8080/auth/v1.0, but it result with "curl: (56) Recv failure:"
Trying the same from inside of a container results in "curl: (7) Failed to connect to 127.0.0.1 port 8080 after 0 ms: Couldn't connect to server"

So, SAIO doesn't work for me :)

[clayg (clay-gerrard)]

I can confirm the py2 image is busted

clayg@banana:~/Workspace/vagrant-swift-all-in-one/swift$ docker run -d -p 8022:8080 openstackswift/saio
8a403202fb93fee0d493b7dbeaaba22bd78095b1e3c08a4af19b05bf9cacd6ab
clayg@banana:~/Workspace/vagrant-swift-all-in-one/swift$ docker run -d -p 8033:8080 openstackswift/saio:py3
b55bd3eb9f432ce4fb63dec7fc116bb55aa61b533fa77b25468ee7f17cd294de
clayg@banana:~/Workspace/vagrant-swift-all-in-one/swift$ curl http://127.0.0.1:8022/info
curl: (56) Recv failure: Connection reset by peer
clayg@banana:~/Workspace/vagrant-swift-all-in-one/swift$ curl http://127.0.0.1:8033/info
{"swift": {"version": "2.33.0.dev21", "strict_cors_mode": true, "policies": [{"name": "1replica", "aliases": "1replica", "default": true}], "allow_account_management": true, "account_autocreate": true, "max_file_size": 5368709122, "max_meta_name_length": 128, "max_meta_value_length": 256, "max_meta_count": 90, "max_meta_overall_size": 4096, "max_header_size": 8192, "max_object_name_length": 1024, "container_listing_limit": 10000, "account_listing_limit": 10000, "max_account_name_length": 256, "max_container_name_length": 256, "extra_header_count": 0}, "symlink": {"symloop_max": 2, "static_links": true}, "versioned_writes": {"allowed_flags": ["x-versions-location", "x-history-location"]}, "object_versioning": {}, "slo": {"max_manifest_segments": 1000, "max_manifest_size": 8388608, "yield_frequency": 10, "min_segment_size": 1, "allow_async_delete": true}, "account_quotas": {}, "container_quotas": {}, "staticweb": {}, "tempauth": {"account_acls": true}, "s3api": {"max_bucket_listing": 1000, "max_parts_listing": 1000, "max_upload_part_num": 1000, "max_multi_delete_objects": 1000, "allow_multipart_uploads": true, "min_segment_size": 5242880, "s3_acl": false}, "ratelimit": {"account_ratelimit": 0.0, "max_sleep_time_seconds": 60.0, "container_ratelimits": [], "container_listing_ratelimits": []}, "tempurl": {"methods": ["GET", "HEAD", "PUT", "POST", "DELETE"], "incoming_remove_headers": ["x-timestamp"], "incoming_allow_headers": [], "outgoing_remove_headers": ["x-object-meta-*"], "outgoing_allow_headers": ["x-object-meta-public-*"], "allowed_digests": ["sha1", "sha256", "sha512"], "deprecated_digests": ["sha1"]}, "bulk_upload": {"max_containers_per_extraction": 10000, "max_failed_extractions": 1000}, "bulk_delete": {"max_deletes_per_request": 10000, "max_failed_deletes": 1000}, "etag_quoter": {"enable_by_default": false}}
clayg@banana:~/Workspace/vagrant-swift-all-in-one/swift$ curl http://127.0.0.1:8022/info
curl: (56) Recv failure: Connection reset by peer

It looks like some part of the pre-req install script is failing.

As I work around I suggest we update the instructions to recommend using the py3 image (maybe drop the py2 image entirely?)

[akka (victor-accarini)]

The problem lies when building the PyEClib using pip:

pip-version: pip 20.3.4

```
    /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../liberasurecode.so: unknown type [0x13] section `.relr.dyn'
    /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../x86_64-alpine-linux-musl/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../liberasurecode.so when searching for -lerasurecode
    /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/liberasurecode.so: unknown type [0x13] section `.relr.dyn'
    /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../x86_64-alpine-linux-musl/bin/ld: skipping incompatible /usr/lib/liberasurecode.so when searching for -lerasurecode
    collect2: error: ld returned 1 exit status
    error: command 'gcc' failed with exit status 1
```

I was able to make the build work:

- Starting a docker with the python2 alpine version(alpine:3.15.6)
- Downloading and building the library from scratch following almost all the steps in here: https://git.alpinelinux.org/aports/tree/testing/liberasurecode/APKBUILD?id=33283848034c9885d984c8e8697c645c57324938
- Then running the pip install -r requirements.txt

For some reason when installing from the alpine package the `ld` deems the library incompatible, but running `file /usr/lib/liberasurecode.so.1.6.3` in both the apk and manually built they seem the same:

Manually built:
/usr/lib/liberasurecode.so.1.6.3: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped

Package installation:
/usr/lib/liberasurecode.so.1.6.3: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=aabb6c883dcbfe83c253e1734437a9d51ea4b254, stripped

Couldn't figure out why that happens...

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/swift/+/896450
Committed: https://opendev.org/openstack/swift/commit/a8be689fc74d1a3d1cf0220e3d4f6ffb087bb1e7
Submitter: "Zuul (22348)"
Branch: master

commit a8be689fc74d1a3d1cf0220e3d4f6ffb087bb1e7
Author: Tim Burke <email address hidden>
Date: Thu Jun 27 14:33:15 2024 -0700

    Get rid of py2 docker image builds; switch "latest" to py3

    Continue also tagging it "py3" so any users of that tag don't become
    stuck in time.

    Closes-Bug: #2037268
    Closes-Bug: #2070029
    Change-Id: I38d9469238d2eb6647414c1107e68ff6f3a15797

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: feature/mpu
Review: https://review.opendev.org/c/openstack/swift/+/925875

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/swift/+/925875
Committed: https://opendev.org/openstack/swift/commit/31b3823148bbda17d97a34b1fd7dd5cb389a91bb
Submitter: "Zuul (22348)"
Branch: feature/mpu

commit becb3ffc1a6cc39fa506ec130c92dc4efac0234b
Author: Matthew Oliver <email address hidden>
Date: Thu Aug 15 14:20:06 2024 +1000

    tests: Attempt to use configured tmp in xprofile tests

    My home server has more strict controls on /tmp as it run selinux etc.
    When running unittests and the default log_filename_prefix deep under
    /tmp gets permission denied. It would be better to override this setting
    in the tests with a good known tmp location

    Change-Id: I6c95ca3a0045a8f268802c6abb633bdfb0e56b73

commit 2e11ac32dac6ecdfc890adb4b1fa75dfd4eb5419
Author: Tim Burke <email address hidden>
Date: Tue Nov 14 14:57:06 2023 -0800

    docs: Simplify reload-process-tree SVGs

    Those were so unwieldy as to be uneditable before.

    Change-Id: Ic9f4a0ea6b8e18e1624c516890ab69884a299773

commit 92eebe24c6837ef36302c801547c2de2e2726b2a
Author: Alistair Coles <email address hidden>
Date: Wed Aug 21 14:05:23 2024 +0100

    Improve test coverage for proxy object DELETE and POST

    Add unit tests for the proxy object controller to cover object DELETE
    and POST scenarios.

    Change-Id: I625a4cf03ee9d4a270d60fa2dc9795b36bb36bf1

commit 87bf4bf5da2cb0c8f640d96cd4304bec422dbaab
Author: Alistair Coles <email address hidden>
Date: Fri Aug 23 10:53:07 2024 +0100

    sharder: rename state to db_state when it's the DB state

    Sharding involves both container DB state transitions and ShardRange
    state transitions. To avoid confusion, always use db_state as the var
    name when referring to the container DB state value.

    Change-Id: Iaaf494fd4e02017005cb3811b673f967bd6b5e1d

commit d830703a32d16d4618a30684da92b78bf48deff6
Author: Alistair Coles <email address hidden>
Date: Thu Aug 22 12:11:47 2024 +0100

    Setup proxy object GET and HEAD tests correctly

    Some unit tests for the proxy object GET and HEAD path were setup with
    insufficient mock responses. The mock connection would raise
    StopIteration exceptions once the mock responses were exhausted, which
    the object controller would handle as if they were error responses,
    potentially distorting the test scenario.

    This patch makes the set_http_connect context manager check for
    unexpected requests and raise an AssertionError if any are found.

    Change-Id: I47774396d9d0a78ebceea6c628c9412b3ad67a11

commit e6b73612d1dcd0bace2361338e6ae82eb591282b
Author: Matthew Oliver <email address hidden>
Date: Tue Aug 13 17:04:40 2024 +1000

    FakeStatsdClient: Stop issuing DNS calls for host.

    Running unittests on my home server, even though is a beast, would be
    painfully slow. Running them on my laptop ran much faster. I tried
    everything and couldn't figure it out.
    Chris, co-author, dug in and after we ran out of options he fired up his
    packet capture and realised most tests were issuing DNS queries for
    `host.`. On my home server, it runs ipv6 dual stack, so thes...

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/swift 2.34.0 release.