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, 20 May 2016 15:01:19 +0200 [thread overview]
Message-ID: <573F0A9F.6000704@suse.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1605120905220.23446@cpach.fuggernut.com>
On 05/12/2016 03:06 PM, Sage Weil wrote:
> On Mon, 11 Apr 2016, Owen Synge wrote:
>> On 04/08/2016 10:57 PM, Owen Synge wrote:
>>> 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.
>>
>> ceph-deploy bug raised:
>>
>> http://tracker.ceph.com/issues/15451
>>
>> PR submitted:
>>
>> https://github.com/ceph/ceph-deploy/pull/393
>
> Hey Owen-
>
> Now that jewel is out, now would be a good time to make this change. The
> ceph-deploy pr looks basically ready to go, minus a doc piece and a run
> through the ceph-deploy suite. Yuri can probably handle the
> latter.
>
> Then we can do the ceph.git changes to kill the ceph-create-keys task...
Dear Sage,
Sorry for the delay, I had a big pile of downstream work and test suite
development to do for my salt work, I have now added some documentation.
I hope Yuri can do the latter as I really dont know "the ceph-deploy suite".
Best wishes
Owen
--
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-05-20 13:01 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 [this message]
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=573F0A9F.6000704@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.