S3上的Openstack SWIFT代理服务器请求格式不正确

我正在尝试使用Devstack（使用Devstack配置文件-local.conf中的stable/newton分支）为开发人员设置S3测试台。虽然我能够使用CLI（openstack container/object，swift）浏览容器和对象，但我无法使用s3curl访问容器。在日志中（完整日志可在下面的链接中找到），我在请求处理的最后阶段看到两个不同的URL：

-------------本地发出的“openstack容器列表”命令

proxy-server: Using identity: {'service_roles': [], 'roles': [u'admin'],
'project_domain': (u'default', u'Default'), 'auth_version': 3,
'user': (u'eac0298a83e44b12b2c08aa98e9b1c9a', u'admin'),
'user_domain': (u'default', u'Default'),
'tenant': (u'2d7365b17c8147e9aead99f870125d31', u'admin')}
(txn: txda7984e9e1f04b7792920-005811ca49)
[ ... ]
proxy-server: de.vs.ta.ck de.vs.ta.ck 27/Oct/2016/09/35/05 GET
/v1/AUTH_2d7365b17c8147e9aead99f870125d31%3Fformat%3Djson HTTP/1.0
200 - osc-lib keystoneauth1/2.14.0 python-requests/2.11.1 CPython/2.7.12
a5ef5769d7ef... - 42 - txda7984e9e1f04b7792920-005811ca49 - 0.0881
- - 1477560905.352745056 1477560905.440839052 -

您可以在上面的请求中看到正确的URL

-------------使用re.mo.te.host中的s3curl进行S3会话

proxy-server: Using identity: {'service_roles': [], 'roles': [u'admin'],
'project_domain': (u'default', u'Default'), 'auth_version': 3,
'user': (u'eac0298a83e44b12b2c08aa98e9b1c9a', u'admin'),
'user_domain': (u'default', u'Default'),
'tenant': (u'2d7365b17c8147e9aead99f870125d31', u'admin')}
(txn: tx61f057911f3e475eb1962-005811c95a)
[ ... ]
proxy-server: re.mo.te.host re.mo.te.host 27/Oct/2016/09/31/07 GET / HTTP/1.0
200 - curl/7.43.0 - - 219 - tx61f057911f3e475eb1962-005811c95a - 0.2074
- - 1477560666.966339111 1477560667.173743010 -

上面的URL格式不正确，当然不会返回任何内容。代理服务器似乎有点问题——由于具有相同的信息，它为不同类型的访问生成不同的请求URL（swift客户端访问与远程S3访问）

对于S3访问，我创建了EC2凭据：

/opt# openstack credential create --type ec2 --project admin admin '{"access" : "admin", "secret" : "adm1n0"}'
blob       :: {"access" : "admin", "secret" : "adm1n0"}
id         :: 8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918
project_id :: 2d7365b17c8147e9aead99f870125d31
type       :: ec2
user_id    :: eac0298a83e44b12b2c08aa98e9b1c9a

当然，还有为admin/admin创建的容器和对象：

/opt# openstack object list c0
+----------+
| Name     |
+----------+
| list.txt |
+----------+

所以，实际上，keystone/swift/swift3集成还可以，问题在于对对象存储的访问。有没有关于什么地方出了问题以及如何进行的想法？代理服务器的完整日志以及proxy-server.conf可从以下链接获得：

---

谢谢大家!

要设置完整URL的日志记录，请在proxy-server.conf（）中使用“force\u swift\u request\u proxy\u log=true”

在纽约的案例中，问题在于容器的命名不正确——我使用了太短的名称（例如c0）。默认情况下，Swift使用非美国东部地区的命名要求，因此名称“c0”似乎无效；看起来bucket名称太短了。来自S3的文档（）-

符合DNS的bucket名称的规则包括：

• 存储桶名称的长度必须至少为3个字符，且不超过63个字符

请尝试将dns_兼容_bucket_names选项设置为False，或对容器名称使用更长的（>3个字符）

感谢SWIFT团队在此问题上的帮助