On Thu, Sep 8, 2016 at 8:23 PM, Casey Bodley <cbodley@xxxxxxxxxx> wrote: > Right, this was the requirement that motivated the work on preselection, so we would only try to authenticate against engines that are properly configured and relevant to the given handler. Which component should be responsible for verifying correctness of configuration? I would say the best candidate is an AuthEngine itself. Some time ago the static can_be_enabled() was proposed. If we need that feature, maybe similar (but better named) method is a way to go? > With respect to changing the auth strategy (i.e. the list of engines configured for a given handler) at runtime, I'm not sure it's worth the complexity at this point, and we certainly don't want to add locking to do this safely. [note that we do have 'dynamic reconfiguration' which pauses the frontend while it reloads RGWRados, so we could use that mechanism to change auth strategy without needing new locks] Great. It looks that at this phase we don't need to have the feature onboard. It's enough to just don't prohibit implementing it in the future. P.S. Sorry for resending this letter, Casey. I had accidentally sent HTML on my mobile client. The message was refused by vger.kernel.org. Regards, Radek -- 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
