All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mykola Golub <mgolub@mirantis.com>
To: Sage Weil <sage@newdream.net>
Cc: Gregory Farnum <greg@gregs42.com>,
	ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: mon: forwarding user commands
Date: Tue, 27 Jan 2015 10:31:16 +0200	[thread overview]
Message-ID: <20150127083115.GB12175@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1501190716540.26676@cobra.newdream.net>

On Mon, Jan 19, 2015 at 07:17:58AM -0800, Sage Weil wrote:
> On Mon, 19 Jan 2015, Gregory Farnum wrote:
> > On Sun, Jan 18, 2015 at 11:02 PM, Mykola Golub <mgolub@mirantis.com> wrote:
> > > On Sun, Jan 18, 2015 at 10:33:05AM -0800, Sage Weil wrote:
> > >> On Sun, 18 Jan 2015, Mykola Golub wrote:
> > >> > Hi Ceph,
> > >> >
> > >> > Right now, for not a monitor leader, if a received command is not
> > >> > supported locally, but is supported by the leader, it is forwarded to
> > >> > the leader.
> > >> >
> > >> > For the recently added "ceph tell mon.x version" it gives a confusing
> > >> > behavior: if the mon.x is not a leader and does not support "version"
> > >> > command yet, but the leader does, the user will receive the version of
> > >> > the leader, and can't be actually sure about a non leader version.
> > >> >
> > >> > I have a patch that fixes this by checking if the received "version"
> > >> > command is forwarded and returning the error in this case:
> > >> >
> > >> > https://github.com/trociny/ceph/commit/98f835357e378b1c5f05b32ba90a8b8537ba1ad8
> > >> >
> > >> > But may be we need a more general solution? We might face a similar
> > >> > issue in future, when adding a new command, which is not expected to
> > >> > be forwarded to the leader (like injectargs).
> > >>
> > >> Yeah.. that works for 'version' but not any other 'tell mon ...' command.
> > >>
> > >> I think the way to do it properly going forward is to add a flags field to
> > >> MMonCommand, with a flag NOFORWARD.
> > >>
> > >> That won't help in the version case, so we can combine it with your
> > >> patch...
> > >
> > > Do you mean
> > >
> > > 1) statically adding the NOFORWARD flag to commands definitions in
> > > MonCommands.h (and to the struct MonCommand in Monitor.h), and then
> > > checking for the flag in Monitor::handle_command(), before forwarding
> > > to the leader, or
> 
> Hmm, this is a cleaner way to approach your change that specifically 
> applies to the new 'version' command.
> 
> > > 2) extending librados API, RadosClient::mon_command(), so a user could
> > > set the flag for any sent command she don't want to be forwarded, and
> > > using this flag for 'ceph tell mon.x ...' commands?
> 
> ..but I think we also want this, so that *any* 'ceph tell mon.whatever 
> ...' command can be flagged to not get forwarded.

I have created a pull request that implements both:

https://github.com/ceph/ceph/pull/3496

The (2) looks not very useful for now -- I suppose currently the only
command that suffers from the describe problem is "version" and it has
"noforward" hard coded. This might change in future though.

-- 
Mykola Golub

  reply	other threads:[~2015-01-27  8:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-18  9:28 mon: forwarding user commands Mykola Golub
2015-01-18 18:33 ` Sage Weil
2015-01-19  7:02   ` Mykola Golub
2015-01-19 14:57     ` Gregory Farnum
2015-01-19 15:17       ` Sage Weil
2015-01-27  8:31         ` Mykola Golub [this message]
2015-01-27 16:20           ` Sage Weil

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=20150127083115.GB12175@gmail.com \
    --to=mgolub@mirantis.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=greg@gregs42.com \
    --cc=sage@newdream.net \
    /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.