rgw: add suport for Swift-at-root dependent features of Swift API #10280
Conversation
This patch fixes to the support for placing the Swift API in the root of URL hierarchy. Unfortunately, the whole concept exhibits a severe side effect: inability to deploy RadosGW in multi-site configuration. The sole reason behind this fix is the fact we claimed in documentation that the feature is available. Fixes: http://tracker.ceph.com/issues/16673 Signed-off-by: Radoslaw Zarzynski <rzarzynski@mirantis.com>
Signed-off-by: Radoslaw Zarzynski <rzarzynski@mirantis.com>
Signed-off-by: Radoslaw Zarzynski <rzarzynski@mirantis.com>
Signed-off-by: Radoslaw Zarzynski <rzarzynski@mirantis.com>
Implementation for swift /info API. Signed-off-by: Pritha Srivastava <prsrivas@redhat.com> Signed-off-by: Radoslaw Zarzynski <rzarzynski@mirantis.com> Conflicts: src/rgw/rgw_common.h src/rgw/rgw_main.cc src/rgw/rgw_rest_swift.cc src/rgw/rgw_rest_swift.h
Signed-off-by: Radoslaw Zarzynski <rzarzynski@mirantis.com>
rzarzynski
force-pushed
the
wip-rgw-swift-at-root-features
branch
from
a2c1b4c
to
dcfd7a9
Compare
|
Rebased due to a merge conflict. |
|
looks good to me |
| rest.register_default_mgr(set_logging(new RGWRESTMgr_S3(s3website_enabled))); | ||
| const bool s3website_enabled = apis_map.count("s3website") > 0; | ||
| // Swift API entrypoint could placed in the root instead of S3 | ||
| const bool swift_at_root = g_conf->rgw_swift_url_prefix == "/"; |
There was a problem hiding this comment.
A question - do we have to take into account if 'swift' api is enabled, while determining whether swift entry point is at root or not?
There was a problem hiding this comment.
I don't think so. The purpose of the swift_at_root is to indicate whether someone requested putting Swift API at root. It could be placed there only if Swift API is enabled and S3 (and S3 website) are turned off.
There was a problem hiding this comment.
ok, i asked this question because what if someone changes the default url prefix to '/' and then decides to disable the swift api altogether, then we could allow the s3/ s3 website to be enabled. This may be a case which may be impossible in a real scenario :)
|
@rzarzynski: Looks good to me too. |
|
Tested as a part of
The failures seem to be unrelated to the changes. The Pritha's commit LGTM. |
|
@rzarzynski Hi ! Would you be willing to try a backport to jewel ? It looks non trivial :-) If you don't have time for that don't worry about it. For the record the corresponding backport issue is http://tracker.ceph.com/issues/17208 |
|
@dachary: Hi Loic! I'm putting the backport on my TODO. I think that |
|
@rzarzynski thanks, much appreciated. If it's easier than it looks, just tell me and I'll give it a try :-) |
This pull request brings:
/crossdomain.xml,/healthcheckand/infoby @pritha-srivastava adapted to this solution).Placing Swift-at root-definitely needs an ultimate solution as the temporary, proposed one exhibits severe side effect: inability to deploy RadosGW in multi-site configuration. This is because some S3 operations working in
system_requestmode are necessary for that to operate.Derogates: #9900, #10069, #10213 and - only if Pritha agrees - #9582.
CC: @pritha-srivastava, @yehudasa, @cbodley.
Tempest and S3 haven't found any regression here. The test for
/infopasses as well though it's really simple - check whether response code is200 OKand body is a properly formatted JSON.