From: Owen Synge <osynge@suse.com>
To: Sage Weil <sweil@redhat.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: Fedora 22 systemd and rgw
Date: Tue, 04 Aug 2015 18:10:18 +0200 [thread overview]
Message-ID: <55C0E3EA.3010607@suse.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1508040604310.22099@cobra.newdream.net>
On 08/04/2015 03:07 PM, Sage Weil wrote:
> On Tue, 4 Aug 2015, Owen Synge wrote:
>> On 08/04/2015 12:13 PM, Owen Synge wrote:
>>> On 08/03/2015 09:07 PM, Sage Weil wrote:
>>>> On Mon, 3 Aug 2015, Owen Synge wrote:
>>
>>> I will check the rgw.
>>
>> It is not working due to missing:
>>
>> /usr/lib/ceph-radosgw/ceph-radosgw-prestart.sh
>>
>> which is a useful check tool, available in this commit:
>>
>> https://github.com/SUSE/ceph/commit/92ef2ecfe0c0c0b0df4c9349310f930057202305
>
> I removed this reference from the unit file, see
>
> https://github.com/ceph/ceph/commit/4d10dc134b817160bab6aecb9f5c08fb2d4f08e6
>
> mainly because I didn't have a copy of the prestart script in my tree.
Ah ok, I lost that during my merges.
> Looking at it now, though, it's not clear to me that any of those steps
> are necessary.
You are correct, the code will run without the prestart script.
the prestart script is _only_ validating that the deamon should run
because the rgw often fails with confusing to end user errors.
The prestart code shoudl in my opinion be mostly implement in C++ in rgw.
> They might be useful in making a legacy install/config
> continue functioning,
No its just validation.
> but I don't think any of the complexity is needed
> for newly created rgw instances, and I'd prefer to make the upgrade
> process look like
>
> - upgrade ceph
> - killall radosgw
> - [optional] rename and sanitize ceph.conf section if there are special
> configs
> - ceph-deploy rgw create $hostname
>
> than worry about trying to keep supporting the kludgey way we used
> to deploy rgw.
Yes, no objections at all.
> FWIW with the wip-systemd branch I was able to deploy new rgw instances
> on fc22 without any issues...
Great news, I hope the wip-systemd branch of ceph-deploy adds hardly any
branching, like the SUSE version adds little, so it should have no
justification to do so, and could even reduce branching in ceph-deploy.
Best regards
Owen
prev parent reply other threads:[~2015-08-04 16:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-28 19:13 systemd status Sage Weil
2015-07-28 22:16 ` Travis Rhoden
2015-07-29 11:25 ` Alex Elsayed
2015-07-29 12:55 ` Sage Weil
2015-07-29 13:09 ` Wyllys Ingersoll
2015-07-29 14:08 ` Alex Elsayed
2015-07-29 14:19 ` Sage Weil
2015-07-29 14:30 ` Alex Elsayed
2015-07-29 14:53 ` Sage Weil
2015-07-29 15:17 ` Alex Elsayed
2015-07-29 16:50 ` Vasiliy Angapov
2015-07-31 13:29 ` Owen Synge
2015-07-30 12:45 ` Sage Weil
2015-07-30 19:40 ` Robert LeBlanc
2015-08-03 8:53 ` Owen Synge
2015-07-31 8:11 ` Owen Synge
2015-07-31 13:23 ` Owen Synge
2015-08-03 19:01 ` Fedora 22 systemd and ceph-deploy Owen Synge
2015-08-03 19:07 ` Sage Weil
2015-08-04 10:13 ` Owen Synge
2015-08-04 12:32 ` Fedora 22 systemd and rgw Owen Synge
2015-08-04 13:07 ` Sage Weil
2015-08-04 16:10 ` Owen Synge [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=55C0E3EA.3010607@suse.com \
--to=osynge@suse.com \
--cc=ceph-devel@vger.kernel.org \
--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.