On Wed, 2017-02-22 at 10:57 +0000, John Spray wrote: > I meant to mention yesterday, I have a branch with the > mds-obeys-blacklist behaviour here: > https://github.com/jcsp/ceph/tree/wip-17980 > Thanks, I'll take a look. > For the other side (blacklisting clients from the MDS), I also > remembered that we currently we have a precedent for special-casing an > mds->OSDMonitor operation, in the form of the MRemoveSnaps message. > > I think the options we currently have for blacklisting clients from the MDS are: > A) Add a new MBlacklist message a la MRemoveSnaps > B) Send a MMonCommand and special case the auth on the mon side to > allow any mds.* entity to run "osd blacklist add" without needing the > usual caps > C) Send a MMonCommand and ask users/scripts setting up Ceph to > explicitly include the mon cap to run the blacklist command. > D) Piggy-back a list of clients to evict on MMDSBeacon, where the MDS > daemon would trim that list once it saw that the blacklist had been > updated to include those clients. > > D is a bit circuitous, but I think it could be interesting as it would > let the mon exercise some discretion on whether to do the client > blacklisting or not, rather than giving the MDSs such power. > > Ugh...I had started working on an approach similar to B/C above, but missed the fact that the mds.* user would need the mon cap. That is a potential problem. A sounds fairly straightforward, and since all of this would require an updated MDS and monitor anyway, it might be the best approach. D sounds clever, but "fiddly". Under what circumstances would you want the monitor to ignore a request from an MDS to blacklist a client? -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
