All of lore.kernel.org
 help / color / mirror / Atom feed
From: Owen Synge <osynge@suse.com>
To: Sage Weil <sweil@redhat.com>
Cc: Gregory Farnum <gfarnum@redhat.com>,
	Ceph Development <ceph-devel@vger.kernel.org>,
	ldachary@redhat.com
Subject: Re: The fundamental evil of "magic" in computing systems -> Was: mon daemon makes authentication side effects on startup
Date: Thu, 7 Apr 2016 17:40:06 +0200	[thread overview]
Message-ID: <57067F56.2000705@suse.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1604070959160.19675@cpach.fuggernut.com>



On 04/07/2016 04:03 PM, Sage Weil wrote:
> On Thu, 7 Apr 2016, Owen Synge wrote:
>> Hi Sage,
>>
>> On 04/07/2016 02:26 PM, Sage Weil wrote:
>>> Hi Owen,
>>>
>>> I never really liked ceph-create-keys either, but it simplified the 
>>> deployment process.  
>>
>> I would propose we do this in two stages.
>>
>> (A) Remove calling the command from the init scripts as a side effect of
>> starting the mon.
>>
>> This allows us to get most of the issues solved.
>>
>> (B) Remove the command.
>>
>> This is the long term goal, which is not as urgent in my opinion but
>> others may disagree.
> 
> Works for me.  We just need to change ceph-deploy and get the other 
> install/deploy tool folks on board before A.

Are you intending to get this into Jewel?

I had assumed this would only be done on master, and only come into the
next release.

As a change to master I felt that we could just do (A) as soon as
ceph-deploy works without the mon boot up scripts calling
ceph-create-keys, ideally without having  ceph-create-keys in
ceph-deploy's process.

We can then file bugs as needed against other install processes that
depend on ceph-create-keys, and they can test against master.

>>> I have no problem with removing it as long as we make
>>> sure the deployment process doesn't too much harder for ceph-deploy users.
>>
>> The documentation for the manual process without using ceph-deploy will
>> need to be changed if we remove calling ceph-create-keys from the boot
>> scripts.
> 
> Yeah.
> 
>> For ceph-deploy users I think we should see if any changes to the
>> process are needed, the next question is will any be wanted?
> 
> Actually, thinking about it a bit more, I don't think ceph-deploy usage 
> has to change at all.  The old way was
> 
>  1. ceph-create-keys creates and installs the keys on the mons
>  2. ceph-deploy gatherkeys or create-initial slurps them up
> 
> We can just change ceph-deploy so it creates and stores them locally, and 
> doesn't store them on the mons at all.  Users don't get the side-effect 
> that the mons have the keys installed, but that is arguably better anyway.
> 
>> https://github.com/SUSE/ceph-deploy/commit/58b030dbe0a964b32f1fbc9a3762e64dd74bf50c
> 
> Instead of this, it should do the same steps as ceph-create-keys (use the 
> mon. internal key to authenticate to create the admin and bootstrap 
> keys), but just write them to the local ceph-dpeloy work dir.

That sounds like a better plan than my idea of just using
ceph-create-keys in ceph-deploy to me.

Best regards

Owen

-- 
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
21284 (AG
Nürnberg)

Maxfeldstraße 5

90409 Nürnberg

Germany
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2016-04-07 15: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 [this message]
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

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=57067F56.2000705@suse.com \
    --to=osynge@suse.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=gfarnum@redhat.com \
    --cc=ldachary@redhat.com \
    --cc=sweil@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.