All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Nelson <mnelson@redhat.com>
To: Owen Synge <osynge@suse.com>, Gregory Farnum <gfarnum@redhat.com>
Cc: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: The fundamental evil of "magic" in computing systems -> Was: mon daemon makes authentication side effects on startup
Date: Thu, 7 Apr 2016 15:40:28 -0500	[thread overview]
Message-ID: <5706C5BC.4090006@redhat.com> (raw)
In-Reply-To: <5704C76C.2050408@suse.com>

On 04/06/2016 03:23 AM, Owen Synge wrote:
> Dear Greg and others,
>
> Thankyou for your very helpful email, as it completely misses my point,
> and that illustrate why this point is so important to be addressed.
>
> I am sure Greg has a deep understanding of this area. But I am pleased
> Greg missed my points from 0-9, Greg's assumption that it is lack of
> understanding on my part (which I am sure is common), clearly
> illustrates where this "magic" of the side effect of starting a mon
> demon becomes becomes "dark magic".
>
> If you object to "magic" and "dark magic" in this email please
> substitute them with "side effect" and "negative consequences of side
> effects" respectively, and you get a more serious reply :)
>

FWIW, I wanted to chime in and say that anything we can do to generally 
reduce instances of "dark magic" like this would be fantastic.

Back when mkcephfs was retired a couple of years ago I had to decide 
what I should replace it with in CBT.  Ultimately it was concern over 
issues like this that lead me to utilize the underlying key/mon/osd 
creation tools directly.  Your point about confusion is totally valid. 
I use ceph-authtool and had only a vague idea that ceph-create-keys even 
existed (and certainly didn't realize the behavior your describing).  I 
create ceph clusters (using CBT) to test performance pretty much daily!

Looking at the documentation, it's pretty easy to miss what's going on:

http://docs.ceph.com/docs/master/man/8/ceph-create-keys/

ceph-authtool is a little better documented:

http://docs.ceph.com/docs/hammer/man/8/ceph-authtool/

It *is* scary when software behaves in mysterious ways.  It doesn't 
invoke trust and it's not the kind of first impression to make with 
already paranoid sysadmins (Being a paranoid ex-sysadmin myself).  I 
think our heart was in the right place to try to reduce the number of 
steps required in ceph-deploy, but it can't come at the expense of 
introducing ambiguity and complexity like this.

Anyway, that's my 2C.

Mark

      parent reply	other threads:[~2016-04-07 20:40 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-05 11:56 mon daemon makes authentication side effects on startup Owen Synge
2016-04-05 18:35 ` John Spray
2016-04-05 23:18   ` Owen Synge
2016-04-05 20:14 ` Gregory Farnum
2016-04-06  8:23   ` The fundamental evil of "magic" in computing systems -> Was: " Owen Synge
2016-04-07  7:49     ` Jens Rosenboom
2016-04-07 11:44       ` Owen Synge
2016-04-07 12:26     ` Sage Weil
2016-04-07 13:54       ` Owen Synge
2016-04-07 14:03         ` Sage Weil
2016-04-07 14:23           ` Gregory Farnum
2016-04-07 14:39             ` Sage Weil
2016-04-07 15:40           ` Owen Synge
2016-04-07 15:43             ` Sage Weil
2016-04-08 20:57               ` Owen Synge
2016-04-11 13:53                 ` Owen Synge
2016-05-12 13:06                   ` Sage Weil
2016-05-20 13:01                     ` Owen Synge
2016-05-25 10:21                       ` Owen Synge
2016-05-25 12:45                         ` Sage Weil
2016-05-30 14:50                           ` Owen Synge
2016-05-31 19:03                           ` Alfredo Deza
2016-04-07 12:33     ` Alfredo Deza
2016-04-07 13:12       ` Owen Synge
2016-04-07 14:22       ` Gregory Farnum
2016-04-07 16:08         ` Owen Synge
2016-04-07 16:51           ` Gregory Farnum
2016-04-07 20:40     ` Mark Nelson [this message]

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=5706C5BC.4090006@redhat.com \
    --to=mnelson@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=gfarnum@redhat.com \
    --cc=osynge@suse.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.