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: Fri, 8 Apr 2016 22:57:30 +0200 [thread overview]
Message-ID: <57081B3A.20601@suse.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1604071143000.19675@cpach.fuggernut.com>
On 04/07/2016 05:43 PM, Sage Weil wrote:
> On Thu, 7 Apr 2016, Owen Synge wrote:
>> 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.
>
> Yeah, too late for jewel.
>
>> 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.
>
> That works for me.
>
> sage
Great,
I have a fix, that is tested and working for ceph-deploy without
depending upon ceph-create-keys based upon a rewrite of the method
ceph-deploy gatherkeys mon-node-01 mon-node-02 mon-node-03
Works nicely for the old and new methods, and seems to have little
impact apart from no new keys are wrote to disk on the mon nodes. OSD's
and rgw can be deployed without change, (I haven’t tested mds)
Previous behavior with the admin keys being deployed can be achieved
simply by executing:
ceph-deploy admin mon-node-01 mon-node-02 mon-node-03
If we definitely what to enforce the admin code being persisted on all
mon nodes can be changed later, but I think its cleaner if we do not.
I will submit a PR on Monday.
Best wishes
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
next prev parent reply other threads:[~2016-04-08 20:57 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 [this message]
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=57081B3A.20601@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.