Hello,
It's a well-known trait of radosgw that an user cannot create new
bucket with a given name if the name is already occupied by other
user's bucket (request to do that will be rejected with 409 Conflict).
This behaviour is entirely expected in S3. However, when it comes
to Swift API, it turns into huge limitation.
In my opinion the root cause lies in how radosgw actually handles
bucket entry points. They might be seen as symlinks which must
be resolved in order to map bucket names exposed to users into
concrete bucket instances:
bucket name -> unique bucket instance ID
It's completely clear we need to preserve backward compatibility.
Thus we cannot simply append ID of user who owns a given
bucket to argument list of mapping function. We would have to
introduce an indirection layer - bucket namespaces:
bucket namespace, bucket name -> unique bucket instance ID
Each already existing user would obtain empty bucket namespace
by default. It will be possible to create user with his own, unique
namespace.
Generally this looks to me as stupidly simple solution. Of course,
it has limitations. At the moment I see following things:
1. We may need to develop a new mechanism for moving buckets
between namespaces in radosgw-admin. The already existing
one for linking/unlinking might be not enough.
2. We will always need ID of namespace in order to access proper
bucket entry points. This is not a problem for requests authorized
through Keystone/TempAuth because user ID is known and thus
BNS may be easily calculated.
Anonymous access/TempURL for bucket with non-empty namespace
is a different story. In this case BNS must be provided explicitly.
Swift resolves the problem by having account name as a part of URL.
We could go the same way. This would be extended by decoupling
rgw_user used for storage access purposes from the one for
authorizing a given operation (RGWOp::verify_permission() method).
I would like to ask for reviews of the idea and feedback.
Best regards,
Radoslaw Zarzynski
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
