From: Jeff Layton <jlayton@redhat.com>
To: John Spray <jspray@redhat.com>,
Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: blacklisting etc
Date: Wed, 22 Feb 2017 06:30:01 -0500 [thread overview]
Message-ID: <1487763001.2886.1.camel@redhat.com> (raw)
In-Reply-To: <CALe9h7c8YtA3YPUkwtOQzvqu-DTQpFXAHxvjUOdd-Ywx_9ccNg@mail.gmail.com>
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@redhat.com>
next prev parent reply other threads:[~2017-02-22 11:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-22 10:57 blacklisting etc John Spray
2017-02-22 11:30 ` Jeff Layton [this message]
2017-02-22 11:51 ` John Spray
2017-02-22 20:57 ` Sage Weil
2017-02-24 11:28 ` John Spray
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1487763001.2886.1.camel@redhat.com \
--to=jlayton@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=jspray@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.