On Mon, 26 Oct 2015 16:09:41 +0100 Radoslaw Zarzynski <[email protected]> wrote:
> Those are the reasons I’m behind keeping rgw_user even if the > entire information it carries would be solely an ID string. Okay. It felt a little obfuscatory but perhaps it's my kernel background talking. > Yeah, bucket namespace is a part of account/RGWUserInfo*. Property > “has_own_bns” even now is serialized together with RGWUserInfo. Very well, we're good. > > The rgw_swift_create_account_with_bns shold go away with rgw_user. > > Option "rgw_swift_create_account_with_bns" is needed mostly due to > integration with OpenStack (Keystone) when accounts* are automatically > created at first access. Without the parameter you would lose ability to > tell radosgw what is more important for you: compliance with Swift API > or previous behavior that still may be useful in some cases. Creating > massive amount of accounts by hand might not be an option here. I'm buying the logic here: at the time of auto-creation, we do not possess the information about the account being auto-created wanting BNS or not. Still, it feels unsatisfactory. I'd rather look into some sort of user attributes in Keystone or whatnot. I'll investigate and report. > > The rgw_swift_account_in_url should be possible to incorporate > > in a compatible fashion (it does not add an extra next_tok()). > > According to "rgw_swift_account_in_url": I don’t see viable method for > deducing whether two tokens in URL refer to 1) account and bucket or > 2) bucket and object. Of course, we may apply some kind of heuristic > like scanning the first token for auth prefix (eg. “AUTH_”, “KEY_”) but > this would introduce limitations on bucket naming. That makes sense, but it's not how I read the actual code. I'll look again. -- Pete -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
