Re: Ceph-deploy for FreeBSD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20-04-17 20:18, Gregory Farnum wrote:
> On Thu, Apr 20, 2017 at 11:11 AM, Nathan Cutler <ncutler@xxxxxxx> wrote:
>> Hi Willem:
>>
>> It sounds like you are trying to use the sysvinit scripts? These have been
>> unmaintained (presumably with lots of weeds growing up) since infernalis.
>> Until now I have been assuming that all init systems other than systemd
>> (sysvinit, upstart, etc.) are deprecated in Ceph.

sysvinit => init-ceph?

If that is the case and is "abandoned", I could start making it more to
my liking to use it under FreeBSD. FreeBSD does not (yet) have this wild
choice of init systems.

Attempts to port Linux one to FreeBSD are in progress, but if they make
it to a large crowd is questionable. Unless it is incorporated in the
the FreeBSD release itself.

> Yeah. In particular, the scripts generally set up some magic to turn
> on daemons instead of enumerating them in the ceph.conf. I forget how
> the OSDs work but it's some hotplug system, and I think maybe the
> monitor scripts just look for any monitor directories and start them?
> Don't really remember.

So systemd is digging around in /dev and /sys proding for devices with
Ceph properties, and then starts the required ceph-(mon|osd|mds|mgr).
Or Udev-events telling systemd to act on a device that presents itself
in the system?

So on an average system there is no OSD info in /etc/ceph/ceph.conf

> -Greg
> 
>> Cheers,
>> Nathan
>>
>>
>> On 04/20/2017 10:55 AM, Willem Jan Withagen wrote:
>>>
>>> On 19-4-2017 22:47, Gregory Farnum wrote:
>>>>
>>>> On Fri, Apr 14, 2017 at 1:44 PM, Willem Jan Withagen <wjw@xxxxxxxxxxx>
>>>> wrote:
>>>>>
>>>>> Having solved the first few step in ceph-deploy, I can now get to the
>>>>> point where it actually wants to start the first monitor.
>>>>> Like:
>>>>>     /usr/local/bin/ceph-deploy mon create-initial
>>>>>
>>>>> And if I look at the other platform booting the inital monitor is
>>>>> started thru the init|systemd|upstart....
>>>>>
>>>>> However under FreeBSD bsdrc I require atleast in ceph.conf
>>>>> [mon]
>>>>>     host = cephtest
>>>>>
>>>>> This is not the case on the other platforms?
>>>>>
>>>>> And how would I otherwise get this into the ceph.conf?
>>>>
>>>>
>>>> I think you're running into some annoying deployment sharp edges here.
>>>> The monitor "host" config value has gone in and out of being necessary
>>>> at various times — the whole monitor boot sequence is pretty finicky
>>>> so I've added Joao to the thread. It's possible that the way things
>>>> are default-configured in FreeBSD that's necessary to work around some
>>>> other default configs?
>>>
>>>
>>> Hi Greg, Joao,
>>>
>>> Could very well be like you describe...
>>>
>>> The call sequence in of course rather convoluted:
>>>
>>>         ceph-deply
>>>         -> remote call ceph-disk prepare
>>>         -> remote call ceph-disk activat
>>>
>>> And expect after the activate to actually have a running OSD.
>>> But to do so, ceph-disk calls the FreeBSD init script:
>>>         service ceph start osd.x
>>> that activates actual initscript:
>>>         /usr/local/etc/rc.d/ceph
>>> which calls:
>>>         init-ceph
>>>
>>> And init-ceph goes thru /etc/ceph/ceph.conf for OSD that it can start on
>>> this host. Now if the OSD description/config is not there, it doesn't
>>> get started.
>>>
>>> I'm doing the service -> rc.d/ceph -> init-ceph way, because that seems
>>> to me the natural way of doing things, and that will take into account
>>> all the settings/bits/other stuff that is set on that host.
>>> AND by keeping init-ceph as main executor, I can try to keep in pace
>>> with the code in the ceph-repo.
>>>
>>> So I guess the best fix is to add routines to add the OSD to the config
>>> and then copy it to the remote host.
>>>
>>> Why would it be not wanted on the other systems?
>>> Otherwise I'd call those adds only from the FreeBSD init part.
>>>
>>> --WjW
>>>
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>

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



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux