From: Gregory Farnum <greg@gregs42.com>
To: Mykola Golub <mgolub@mirantis.com>
Cc: Sage Weil <sage@newdream.net>, ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: mon: forwarding user commands
Date: Mon, 19 Jan 2015 06:57:58 -0800 [thread overview]
Message-ID: <CAC6JEv_fnZhVymT0d7dO2iJxeZNp7mmy9WxDQEeYj1qQg-fppg@mail.gmail.com> (raw)
In-Reply-To: <20150119070248.GA14221@gmail.com>
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
>
> 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?
>
> I think you mean (2), but just to be sure, before coding this...
I think it would be (1), but you'd have to check it both before
forwarding and after receipt of a forward. That way we can determine
whenever we add commands if it should be forwarded or not, instead of
letting users get it wrong?
-Greg
next prev parent reply other threads:[~2015-01-19 14:58 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 [this message]
2015-01-19 15:17 ` Sage Weil
2015-01-27 8:31 ` Mykola Golub
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=CAC6JEv_fnZhVymT0d7dO2iJxeZNp7mmy9WxDQEeYj1qQg-fppg@mail.gmail.com \
--to=greg@gregs42.com \
--cc=ceph-devel@vger.kernel.org \
--cc=mgolub@mirantis.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.