Mourning the demise of mkcephfs

Mourning the demise of mkcephfs

[Dave (Bob)]

The utility mkcephfs seemed to work, it was very simple to use and
apparently effective.

It has been deprecated in favour of something called ceph-deploy, which
does not work for me.

I've ignored the deprecation messages until now, but in going from 70 to
72 I find that mkcephfs has finally gone.

I have tried ceph-deploy, and it seems to be tied in to specific
'distributions' in some way.

It is unuseable for me at present, because it reports:

[ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported:


I therefore need to go back to first principles, but the documentation
seems to have dropped descriptions of driving ceph without smoke and
mirrors.

The direct approach may be more laborious, but at least it would not
depend on anything except ceph itself.

Maybe I need to step back a version or two, set up my cluster with
mkcephfs, then switch back to the latest to use it.

I'll search the documentation again.

Re: Mourning the demise of mkcephfs

[Mark Kirkwood]

Hi,

Loic posted a script he uses for testing setups without ceph-deploy:

http://www.spinics.net/lists/ceph-devel/msg16895.html
http://dachary.org/wp-uploads/2013/10/micro-osd.txt

it probably has enough steps in it for you to adapt.

Regards

Mark

P.s: what *is* your platform? It might not be too hard to get 
ceph-deploy going on it :-)

On 12/11/13 06:51, Dave (Bob) wrote:
> The utility mkcephfs seemed to work, it was very simple to use and
> apparently effective.
>
> It has been deprecated in favour of something called ceph-deploy, which
> does not work for me.
>
> I've ignored the deprecation messages until now, but in going from 70 to
> 72 I find that mkcephfs has finally gone.
>
> I have tried ceph-deploy, and it seems to be tied in to specific
> 'distributions' in some way.
>
> It is unuseable for me at present, because it reports:
>
> [ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported:
>
>
> I therefore need to go back to first principles, but the documentation
> seems to have dropped descriptions of driving ceph without smoke and
> mirrors.
>
> The direct approach may be more laborious, but at least it would not
> depend on anything except ceph itself.
>
> Maybe I need to step back a version or two, set up my cluster with
> mkcephfs, then switch back to the latest to use it.
>
> I'll search the documentation again.
> --
> 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
>

Re: Mourning the demise of mkcephfs

[Wido den Hollander]

On 11/11/2013 06:51 PM, Dave (Bob) wrote:
> The utility mkcephfs seemed to work, it was very simple to use and
> apparently effective.
>
> It has been deprecated in favour of something called ceph-deploy, which
> does not work for me.
>
> I've ignored the deprecation messages until now, but in going from 70 to
> 72 I find that mkcephfs has finally gone.
>
> I have tried ceph-deploy, and it seems to be tied in to specific
> 'distributions' in some way.
>
> It is unuseable for me at present, because it reports:
>
> [ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported:
>
>
> I therefore need to go back to first principles, but the documentation
> seems to have dropped descriptions of driving ceph without smoke and
> mirrors.
>
> The direct approach may be more laborious, but at least it would not
> depend on anything except ceph itself.
>

I myself am not a very big fan of ceph-deploy as well. Most 
installations I do are done by bootstrapping the monitors and osds manually.

I have some homebrew scripts for this, but I mainly use Puppet to make 
sure all the packages and configuration is present on the nodes and 
afterwards it's just a matter of adding the OSDs and formatting their 
disks once.

The guide to bootstrapping a monitor: 
http://eu.ceph.com/docs/master/dev/mon-bootstrap/

When the monitor cluster is running you can start generating cephx keys 
for the OSDs and add them to the cluster: 
http://eu.ceph.com/docs/master/rados/operations/add-or-rm-osds/

I don't know if the docs are 100% correct. I've done this so many times 
that I do a lot of things without even reading the docs, so there might 
be a typo in it somewhere. If so, report it so it can be fixed.

Where I think that ceph-deploy works for a lot of people I fully 
understand that some people just want to manually bootstrap a Ceph 
cluster from scratch.

Wido

> Maybe I need to step back a version or two, set up my cluster with
> mkcephfs, then switch back to the latest to use it.
>
> I'll search the documentation again.
> --
> 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
>


-- 
Wido den Hollander
42on B.V.

Phone: +31 (0)20 700 9902
Skype: contact42on

Re: Mourning the demise of mkcephfs

[Ketor D]

Hi Bob:
      mkcephfs is still usable in 0.72 with a little path.We are still
using mkcephfs on 0.72 because ceph-deploy is not good enough.

You need to patch mkcephfs.in and init-ceph.in to do this.

The patch of mkcephfs.in is you need to modify three symbols:
    BINDIR=/usr/bin
    LIBDIR=/usr/lib64/ceph
    ETCDIR=/etc/ceph
to the real path in your system.

The patch of init-ceph.in is here:
Signed-off-by: Ketor D <d.ketor@gmail.com>
---
diff --git "a/src/init-ceph.in" "b/src/init-ceph.in"
index 7399abb..cf2eaa6 100644
--- "a/src/init-ceph.in"
+++ "b/src/init-ceph.in"
@@ -331,7 +331,8 @@ for name in $what; do
  -- \
  $id \
  ${osd_weight:-${defaultweight:-1}} \
- $osd_location"
+ $osd_location \
+ || :"
  fi
     fi

On Tue, Nov 12, 2013 at 3:22 PM, Wido den Hollander <wido@42on.com> wrote:
> On 11/11/2013 06:51 PM, Dave (Bob) wrote:
>>
>> The utility mkcephfs seemed to work, it was very simple to use and
>> apparently effective.
>>
>> It has been deprecated in favour of something called ceph-deploy, which
>> does not work for me.
>>
>> I've ignored the deprecation messages until now, but in going from 70 to
>> 72 I find that mkcephfs has finally gone.
>>
>> I have tried ceph-deploy, and it seems to be tied in to specific
>> 'distributions' in some way.
>>
>> It is unuseable for me at present, because it reports:
>>
>> [ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported:
>>
>>
>> I therefore need to go back to first principles, but the documentation
>> seems to have dropped descriptions of driving ceph without smoke and
>> mirrors.
>>
>> The direct approach may be more laborious, but at least it would not
>> depend on anything except ceph itself.
>>
>
> I myself am not a very big fan of ceph-deploy as well. Most installations I
> do are done by bootstrapping the monitors and osds manually.
>
> I have some homebrew scripts for this, but I mainly use Puppet to make sure
> all the packages and configuration is present on the nodes and afterwards
> it's just a matter of adding the OSDs and formatting their disks once.
>
> The guide to bootstrapping a monitor:
> http://eu.ceph.com/docs/master/dev/mon-bootstrap/
>
> When the monitor cluster is running you can start generating cephx keys for
> the OSDs and add them to the cluster:
> http://eu.ceph.com/docs/master/rados/operations/add-or-rm-osds/
>
> I don't know if the docs are 100% correct. I've done this so many times that
> I do a lot of things without even reading the docs, so there might be a typo
> in it somewhere. If so, report it so it can be fixed.
>
> Where I think that ceph-deploy works for a lot of people I fully understand
> that some people just want to manually bootstrap a Ceph cluster from
> scratch.
>
> Wido
>
>
>> Maybe I need to step back a version or two, set up my cluster with
>> mkcephfs, then switch back to the latest to use it.
>>
>> I'll search the documentation again.
>> --
>> 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
>>
>
>
> --
> Wido den Hollander
> 42on B.V.
>
> Phone: +31 (0)20 700 9902
> Skype: contact42on
>
> --
> 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

Re: Mourning the demise of mkcephfs

[Dave (Bob)]

On 12/11/2013 07:41, Ketor D wrote:
> Hi Bob:
>       mkcephfs is still usable in 0.72 with a little path.We are still
> using mkcephfs on 0.72 because ceph-deploy is not good enough.
>
> You need to patch mkcephfs.in and init-ceph.in to do this.
>
> The patch of mkcephfs.in is you need to modify three symbols:
>     BINDIR=/usr/bin
>     LIBDIR=/usr/lib64/ceph
>     ETCDIR=/etc/ceph
> to the real path in your system.
>
> The patch of init-ceph.in is here:
> Signed-off-by: Ketor D <d.ketor@gmail.com>
> ---
> diff --git "a/src/init-ceph.in" "b/src/init-ceph.in"
> index 7399abb..cf2eaa6 100644
> --- "a/src/init-ceph.in"
> +++ "b/src/init-ceph.in"
> @@ -331,7 +331,8 @@ for name in $what; do
>   -- \
>   $id \
>   ${osd_weight:-${defaultweight:-1}} \
> - $osd_location"
> + $osd_location \
> + || :"
>   fi
>      fi
>
> On Tue, Nov 12, 2013 at 3:22 PM, Wido den Hollander <wido@42on.com> wrote:
>> On 11/11/2013 06:51 PM, Dave (Bob) wrote:
>>> The utility mkcephfs seemed to work, it was very simple to use and
>>> apparently effective.
>>>
>>> It has been deprecated in favour of something called ceph-deploy, which
>>> does not work for me.
>>>
>>> I've ignored the deprecation messages until now, but in going from 70 to
>>> 72 I find that mkcephfs has finally gone.
>>>
>>> I have tried ceph-deploy, and it seems to be tied in to specific
>>> 'distributions' in some way.
>>>
>>> It is unuseable for me at present, because it reports:
>>>
>>> [ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported:
>>>
>>>
>>> I therefore need to go back to first principles, but the documentation
>>> seems to have dropped descriptions of driving ceph without smoke and
>>> mirrors.
>>>
>>> The direct approach may be more laborious, but at least it would not
>>> depend on anything except ceph itself.
>>>
>> I myself am not a very big fan of ceph-deploy as well. Most installations I
>> do are done by bootstrapping the monitors and osds manually.
>>
>> I have some homebrew scripts for this, but I mainly use Puppet to make sure
>> all the packages and configuration is present on the nodes and afterwards
>> it's just a matter of adding the OSDs and formatting their disks once.
>>
>> The guide to bootstrapping a monitor:
>> http://eu.ceph.com/docs/master/dev/mon-bootstrap/
>>
>> When the monitor cluster is running you can start generating cephx keys for
>> the OSDs and add them to the cluster:
>> http://eu.ceph.com/docs/master/rados/operations/add-or-rm-osds/
>>
>> I don't know if the docs are 100% correct. I've done this so many times that
>> I do a lot of things without even reading the docs, so there might be a typo
>> in it somewhere. If so, report it so it can be fixed.
>>
>> Where I think that ceph-deploy works for a lot of people I fully understand
>> that some people just want to manually bootstrap a Ceph cluster from
>> scratch.
>>
>> Wido
>>
>>
>>> Maybe I need to step back a version or two, set up my cluster with
>>> mkcephfs, then switch back to the latest to use it.
>>>
>>> I'll search the documentation again.
>>> --
>>> 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
>>>
>>
>> --
>> Wido den Hollander
>> 42on B.V.
>>
>> Phone: +31 (0)20 700 9902
>> Skype: contact42on
>>
>> --
>> 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
> --
> 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
>
>
Thank you...
David

Re: Mourning the demise of mkcephfs

[Dave (Bob)]

On 12/11/2013 07:22, Wido den Hollander wrote:
> On 11/11/2013 06:51 PM, Dave (Bob) wrote:
>> The utility mkcephfs seemed to work, it was very simple to use and
>> apparently effective.
>>
>> It has been deprecated in favour of something called ceph-deploy, which
>> does not work for me.
>>
>> I've ignored the deprecation messages until now, but in going from 70 to
>> 72 I find that mkcephfs has finally gone.
>>
>> I have tried ceph-deploy, and it seems to be tied in to specific
>> 'distributions' in some way.
>>
>> It is unuseable for me at present, because it reports:
>>
>> [ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported:
>>
>>
>> I therefore need to go back to first principles, but the documentation
>> seems to have dropped descriptions of driving ceph without smoke and
>> mirrors.
>>
>> The direct approach may be more laborious, but at least it would not
>> depend on anything except ceph itself.
>>
>
> I myself am not a very big fan of ceph-deploy as well. Most
> installations I do are done by bootstrapping the monitors and osds
> manually.
>
> I have some homebrew scripts for this, but I mainly use Puppet to make
> sure all the packages and configuration is present on the nodes and
> afterwards it's just a matter of adding the OSDs and formatting their
> disks once.
>
> The guide to bootstrapping a monitor:
> http://eu.ceph.com/docs/master/dev/mon-bootstrap/
>
> When the monitor cluster is running you can start generating cephx
> keys for the OSDs and add them to the cluster:
> http://eu.ceph.com/docs/master/rados/operations/add-or-rm-osds/
>
> I don't know if the docs are 100% correct. I've done this so many
> times that I do a lot of things without even reading the docs, so
> there might be a typo in it somewhere. If so, report it so it can be
> fixed.
>
> Where I think that ceph-deploy works for a lot of people I fully
> understand that some people just want to manually bootstrap a Ceph
> cluster from scratch.
>
> Wido
>
>> Maybe I need to step back a version or two, set up my cluster with
>> mkcephfs, then switch back to the latest to use it.
>>
>> I'll search the documentation again.
>> -- 
>> 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
>>
>
>
Thank you very much Wido.
David

Re: Mourning the demise of mkcephfs

[Mark Nelson]

FYI, I created a bug for this last week:

http://tracker.ceph.com/issues/6720

Mark

On 11/12/2013 06:22 AM, Dave (Bob) wrote:
> On 12/11/2013 07:22, Wido den Hollander wrote:
>> On 11/11/2013 06:51 PM, Dave (Bob) wrote:
>>> The utility mkcephfs seemed to work, it was very simple to use and
>>> apparently effective.
>>>
>>> It has been deprecated in favour of something called ceph-deploy, which
>>> does not work for me.
>>>
>>> I've ignored the deprecation messages until now, but in going from 70 to
>>> 72 I find that mkcephfs has finally gone.
>>>
>>> I have tried ceph-deploy, and it seems to be tied in to specific
>>> 'distributions' in some way.
>>>
>>> It is unuseable for me at present, because it reports:
>>>
>>> [ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported:
>>>
>>>
>>> I therefore need to go back to first principles, but the documentation
>>> seems to have dropped descriptions of driving ceph without smoke and
>>> mirrors.
>>>
>>> The direct approach may be more laborious, but at least it would not
>>> depend on anything except ceph itself.
>>>
>>
>> I myself am not a very big fan of ceph-deploy as well. Most
>> installations I do are done by bootstrapping the monitors and osds
>> manually.
>>
>> I have some homebrew scripts for this, but I mainly use Puppet to make
>> sure all the packages and configuration is present on the nodes and
>> afterwards it's just a matter of adding the OSDs and formatting their
>> disks once.
>>
>> The guide to bootstrapping a monitor:
>> http://eu.ceph.com/docs/master/dev/mon-bootstrap/
>>
>> When the monitor cluster is running you can start generating cephx
>> keys for the OSDs and add them to the cluster:
>> http://eu.ceph.com/docs/master/rados/operations/add-or-rm-osds/
>>
>> I don't know if the docs are 100% correct. I've done this so many
>> times that I do a lot of things without even reading the docs, so
>> there might be a typo in it somewhere. If so, report it so it can be
>> fixed.
>>
>> Where I think that ceph-deploy works for a lot of people I fully
>> understand that some people just want to manually bootstrap a Ceph
>> cluster from scratch.
>>
>> Wido
>>
>>> Maybe I need to step back a version or two, set up my cluster with
>>> mkcephfs, then switch back to the latest to use it.
>>>
>>> I'll search the documentation again.
>>> --
>>> 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
>>>
>>
>>
> Thank you very much Wido.
> David
> --
> 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
>

Re: Mourning the demise of mkcephfs

[Mark Nelson]

I forgot to mention you can change the ceph-init script in the packaged 
version too if you don't want to compile ceph from source.  It's a very 
easy modification and it should work fine afterwards.

Mark

On 11/12/2013 07:56 AM, Mark Nelson wrote:
> FYI, I created a bug for this last week:
>
> http://tracker.ceph.com/issues/6720
>
> Mark
>
> On 11/12/2013 06:22 AM, Dave (Bob) wrote:
>> On 12/11/2013 07:22, Wido den Hollander wrote:
>>> On 11/11/2013 06:51 PM, Dave (Bob) wrote:
>>>> The utility mkcephfs seemed to work, it was very simple to use and
>>>> apparently effective.
>>>>
>>>> It has been deprecated in favour of something called ceph-deploy, which
>>>> does not work for me.
>>>>
>>>> I've ignored the deprecation messages until now, but in going from
>>>> 70 to
>>>> 72 I find that mkcephfs has finally gone.
>>>>
>>>> I have tried ceph-deploy, and it seems to be tied in to specific
>>>> 'distributions' in some way.
>>>>
>>>> It is unuseable for me at present, because it reports:
>>>>
>>>> [ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported:
>>>>
>>>>
>>>> I therefore need to go back to first principles, but the documentation
>>>> seems to have dropped descriptions of driving ceph without smoke and
>>>> mirrors.
>>>>
>>>> The direct approach may be more laborious, but at least it would not
>>>> depend on anything except ceph itself.
>>>>
>>>
>>> I myself am not a very big fan of ceph-deploy as well. Most
>>> installations I do are done by bootstrapping the monitors and osds
>>> manually.
>>>
>>> I have some homebrew scripts for this, but I mainly use Puppet to make
>>> sure all the packages and configuration is present on the nodes and
>>> afterwards it's just a matter of adding the OSDs and formatting their
>>> disks once.
>>>
>>> The guide to bootstrapping a monitor:
>>> http://eu.ceph.com/docs/master/dev/mon-bootstrap/
>>>
>>> When the monitor cluster is running you can start generating cephx
>>> keys for the OSDs and add them to the cluster:
>>> http://eu.ceph.com/docs/master/rados/operations/add-or-rm-osds/
>>>
>>> I don't know if the docs are 100% correct. I've done this so many
>>> times that I do a lot of things without even reading the docs, so
>>> there might be a typo in it somewhere. If so, report it so it can be
>>> fixed.
>>>
>>> Where I think that ceph-deploy works for a lot of people I fully
>>> understand that some people just want to manually bootstrap a Ceph
>>> cluster from scratch.
>>>
>>> Wido
>>>
>>>> Maybe I need to step back a version or two, set up my cluster with
>>>> mkcephfs, then switch back to the latest to use it.
>>>>
>>>> I'll search the documentation again.
>>>> --
>>>> 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
>>>>
>>>
>>>
>> Thank you very much Wido.
>> David
>> --
>> 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
>>
>

Re: Mourning the demise of mkcephfs

[Alfredo Deza]

On Tue, Nov 12, 2013 at 2:22 AM, Wido den Hollander <wido@42on.com> wrote:
> On 11/11/2013 06:51 PM, Dave (Bob) wrote:
>>
>> The utility mkcephfs seemed to work, it was very simple to use and
>> apparently effective.
>>
>> It has been deprecated in favour of something called ceph-deploy, which
>> does not work for me.
>>
>> I've ignored the deprecation messages until now, but in going from 70 to
>> 72 I find that mkcephfs has finally gone.
>>
>> I have tried ceph-deploy, and it seems to be tied in to specific
>> 'distributions' in some way.
>>
>> It is unuseable for me at present, because it reports:
>>
>> [ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported:
>>
>>
>> I therefore need to go back to first principles, but the documentation
>> seems to have dropped descriptions of driving ceph without smoke and
>> mirrors.
>>
>> The direct approach may be more laborious, but at least it would not
>> depend on anything except ceph itself.
>>
>
> I myself am not a very big fan of ceph-deploy as well.

Why not? I definitely want to make it better for users, and any
feedback is super useful. What kind of caveats have
you found that lead you to not use it (or use something completely different) ?

>  Most installations I
> do are done by bootstrapping the monitors and osds manually.
>
> I have some homebrew scripts for this, but I mainly use Puppet to make sure
> all the packages and configuration is present on the nodes and afterwards
> it's just a matter of adding the OSDs and formatting their disks once.
>
> The guide to bootstrapping a monitor:
> http://eu.ceph.com/docs/master/dev/mon-bootstrap/
>
> When the monitor cluster is running you can start generating cephx keys for
> the OSDs and add them to the cluster:
> http://eu.ceph.com/docs/master/rados/operations/add-or-rm-osds/
>
> I don't know if the docs are 100% correct. I've done this so many times that
> I do a lot of things without even reading the docs, so there might be a typo
> in it somewhere. If so, report it so it can be fixed.
>
> Where I think that ceph-deploy works for a lot of people I fully understand
> that some people just want to manually bootstrap a Ceph cluster from
> scratch.
>
> Wido
>
>
>> Maybe I need to step back a version or two, set up my cluster with
>> mkcephfs, then switch back to the latest to use it.
>>
>> I'll search the documentation again.
>> --
>> 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
>>
>
>
> --
> Wido den Hollander
> 42on B.V.
>
> Phone: +31 (0)20 700 9902
> Skype: contact42on
>
> --
> 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

Re: Mourning the demise of mkcephfs

[Alfredo Deza]

On Mon, Nov 11, 2013 at 12:51 PM, Dave (Bob) <dave@bob-the-boat.me.uk> wrote:
> The utility mkcephfs seemed to work, it was very simple to use and
> apparently effective.
>
> It has been deprecated in favour of something called ceph-deploy, which
> does not work for me.
>
> I've ignored the deprecation messages until now, but in going from 70 to
> 72 I find that mkcephfs has finally gone.
>
> I have tried ceph-deploy, and it seems to be tied in to specific
> 'distributions' in some way.

It is\x10! ceph-deploy needs to know what distribution is it talking to
because different distros will install/uninstall packages
with different packages managers. Init scripts will also be different,
so this "distro detection" is a must to provide the same
functionality regardless of what supported distro you might be using.

>
> It is unuseable for me at present, because it reports:
>
> [ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported:
>

That looks like a bug. For the past few months the log output of
ceph-deploy has tried to improve to give as much useful information
as possible.

To get to the bottom of this it would be super helpful to know what
distro you were attempting to connect to, what the actual command was,
and what version of ceph-deploy you were using.

Hopefully, with that information and the (possible) bug fix, it will
mean that more and more people find ceph-deploy as a robust solution
to get
a Ceph cluster up and running.

>
> I therefore need to go back to first principles, but the documentation
> seems to have dropped descriptions of driving ceph without smoke and
> mirrors.
>
> The direct approach may be more laborious, but at least it would not
> depend on anything except ceph itself.
>
> Maybe I need to step back a version or two, set up my cluster with
> mkcephfs, then switch back to the latest to use it.
>
> I'll search the documentation again.
> --
> 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

Re: Mourning the demise of mkcephfs

[Mark Kirkwood]

On 13/11/13 04:53, Alfredo Deza wrote:
> On Mon, Nov 11, 2013 at 12:51 PM, Dave (Bob) <dave@bob-the-boat.me.uk> wrote:
>
>> It is unuseable for me at present, because it reports:
>>
>> [ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported:
>>
> That looks like a bug. For the past few months the log output of
> ceph-deploy has tried to improve to give as much useful information
> as possible.
>
> To get to the bottom of this it would be super helpful to know what
> distro you were attempting to connect to, what the actual command was,
> and what version of ceph-deploy you were using.
>
> Hopefully, with that information and the (possible) bug fix, it will
> mean that more and more people find ceph-deploy as a robust solution
> to get
> a Ceph cluster up and running.
>
>

I believe he is using a self built (or heavily customized) Linux 
installation - so distribution detection is not going to work in this 
case. I'm wondering if there could be some sensible fall back for that, e.g:

- refuse to install or purge
- assume sysv init

so that ceph-deploy can 'do the best it can' in these situations. Thoughts?

Cheers

Mark

Re: Mourning the demise of mkcephfs

[Mark Kirkwood]

On 13/11/13 16:33, Mark Kirkwood wrote:
> On 13/11/13 04:53, Alfredo Deza wrote:
>> On Mon, Nov 11, 2013 at 12:51 PM, Dave (Bob) 
>> <dave@bob-the-boat.me.uk> wrote:
>>
>>> It is unuseable for me at present, because it reports:
>>>
>>> [ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported:
>>>
>> That looks like a bug. For the past few months the log output of
>> ceph-deploy has tried to improve to give as much useful information
>> as possible.
>>
>> To get to the bottom of this it would be super helpful to know what
>> distro you were attempting to connect to, what the actual command was,
>> and what version of ceph-deploy you were using.
>>
>> Hopefully, with that information and the (possible) bug fix, it will
>> mean that more and more people find ceph-deploy as a robust solution
>> to get
>> a Ceph cluster up and running.
>>
>>
>
> I believe he is using a self built (or heavily customized) Linux 
> installation - so distribution detection is not going to work in this 
> case. I'm wondering if there could be some sensible fall back for 
> that, e.g:
>
> - refuse to install or purge
> - assume sysv init
>
> so that ceph-deploy can 'do the best it can' in these situations. 
> Thoughts?
>

Ahem - replying to myself, sorry:

It might be just as easy to allow init to be specified as an option 
(--init INITTYPE). As an aside, for my development (Ubuntu) workstation, 
I'm building ceph from src and using ceph-deploy to install it - *but* 
am switching init to sysv afterwards (I just prefer to use it for that 
situation).

Cheers

Mark

Re: Mourning the demise of mkcephfs

[Dave (Bob)]

I would suggest that it is always dangerous to make assumptions.
If ceph-deploy needs some information, then this should be explicit, and
configurable.
If it needs to know whether initialisation is done by systemd, upstart,
or sysv init, then what is wrong with requesting a config option?

As it happens, ceph-deploy doesn't seem to be what I require as a
mkcephfs replacement.
An earlier exchange with Mark suggests that it wants to involve itself
with the installation of software, and the configuration of startup
mechanisms.
This is not what I want, and it is not any part of what mkcephfs did.

Given that I have ceph installed, and a bunch of disk drives, I need to
be able to drive the ceph applications appropriately to set up the
osd's, keys, and other required data so that I can start the
ceph-osd(s), the ceph-mon(s), and the ceph-mds(s) [which I can do by
typing! (and I can make systemd do it automatically if and when I find
that I'm ready for that)].

This is what mkcephfs did.

The original documentation site gave information on how to perform all
these operations manually. I am not sure that this information is still
available.

Whilst I can see that a kind of 'Windows installer' type of application
could be useful in some circumstances, it is not appropriate to delete
basic instructions and believe that what I referred to as a 'smoke and
mirrors' approach to operation is an adequate substitute.

There has been several helpful replies here, and I thank those people.

Please don't maintain the notion that some 'magic installer' is a proper
substitute for basic and comprehensive 'man pages' and other appropriate
documentation.

I have been tracking ceph development for many tens of revisions; I have
discovered the weakness of BTRFS for ceph (which I use in all cases
except for OSDs, where I take the advice and use XFS); I experiment with
different hardware configurations; I take advantage of all kernel
developments that improve disk I/O performance; I keep working with the
latest kernel and the latest ceph. I am really looking forward to being
able to rely on ceph, it is the answer to many prayers.

My test is to rsync a large amount of data (several terabytes) to a ceph
filesystem and for this to happen without hitch. When this happens, I'll
have confidence. Ceph stresses everything.

I think that this day is now very close.

Very warm regards,
David

On 13/11/2013 03:54, Mark Kirkwood wrote:
> On 13/11/13 16:33, Mark Kirkwood wrote:
>> On 13/11/13 04:53, Alfredo Deza wrote:
>>> On Mon, Nov 11, 2013 at 12:51 PM, Dave (Bob)
>>> <dave@bob-the-boat.me.uk> wrote:
>>>
>>>> It is unuseable for me at present, because it reports:
>>>>
>>>> [ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported:
>>>>
>>> That looks like a bug. For the past few months the log output of
>>> ceph-deploy has tried to improve to give as much useful information
>>> as possible.
>>>
>>> To get to the bottom of this it would be super helpful to know what
>>> distro you were attempting to connect to, what the actual command was,
>>> and what version of ceph-deploy you were using.
>>>
>>> Hopefully, with that information and the (possible) bug fix, it will
>>> mean that more and more people find ceph-deploy as a robust solution
>>> to get
>>> a Ceph cluster up and running.
>>>
>>>
>>
>> I believe he is using a self built (or heavily customized) Linux
>> installation - so distribution detection is not going to work in this
>> case. I'm wondering if there could be some sensible fall back for
>> that, e.g:
>>
>> - refuse to install or purge
>> - assume sysv init
>>
>> so that ceph-deploy can 'do the best it can' in these situations.
>> Thoughts?
>>
>
> Ahem - replying to myself, sorry:
>
> It might be just as easy to allow init to be specified as an option
> (--init INITTYPE). As an aside, for my development (Ubuntu)
> workstation, I'm building ceph from src and using ceph-deploy to
> install it - *but* am switching init to sysv afterwards (I just prefer
> to use it for that situation).
>
> Cheers
>
> Mark
>
>

Re: Mourning the demise of mkcephfs

[Dave (Bob)]

http://eu.ceph.com/docs/master/

Is the location of the documentation that I remember, but have not been
able to find recently.

Thank you Wido.

David

Re: Mourning the demise of mkcephfs

[Mark Nelson]

On 11/14/2013 06:27 AM, Dave (Bob) wrote:
> I would suggest that it is always dangerous to make assumptions.
> If ceph-deploy needs some information, then this should be explicit, and
> configurable.
> If it needs to know whether initialisation is done by systemd, upstart,
> or sysv init, then what is wrong with requesting a config option?
>
> As it happens, ceph-deploy doesn't seem to be what I require as a
> mkcephfs replacement.
> An earlier exchange with Mark suggests that it wants to involve itself
> with the installation of software, and the configuration of startup
> mechanisms.

I am not an expert on ceph-deploy by any means.  ceph-deploy can do 
these thing (install software, startup, etc), but I don't think it 
strictly has to.

> This is not what I want, and it is not any part of what mkcephfs did.
>
> Given that I have ceph installed, and a bunch of disk drives, I need to
> be able to drive the ceph applications appropriately to set up the
> osd's, keys, and other required data so that I can start the
> ceph-osd(s), the ceph-mon(s), and the ceph-mds(s) [which I can do by
> typing! (and I can make systemd do it automatically if and when I find
> that I'm ready for that)].
>
> This is what mkcephfs did.
>
> The original documentation site gave information on how to perform all
> these operations manually. I am not sure that this information is still
> available.
>
> Whilst I can see that a kind of 'Windows installer' type of application
> could be useful in some circumstances, it is not appropriate to delete
> basic instructions and believe that what I referred to as a 'smoke and
> mirrors' approach to operation is an adequate substitute.
>
> There has been several helpful replies here, and I thank those people.
>
> Please don't maintain the notion that some 'magic installer' is a proper
> substitute for basic and comprehensive 'man pages' and other appropriate
> documentation.
>
> I have been tracking ceph development for many tens of revisions; I have
> discovered the weakness of BTRFS for ceph (which I use in all cases
> except for OSDs, where I take the advice and use XFS); I experiment with
> different hardware configurations; I take advantage of all kernel
> developments that improve disk I/O performance; I keep working with the
> latest kernel and the latest ceph. I am really looking forward to being
> able to rely on ceph, it is the answer to many prayers.
>
> My test is to rsync a large amount of data (several terabytes) to a ceph
> filesystem and for this to happen without hitch. When this happens, I'll
> have confidence. Ceph stresses everything.
>
> I think that this day is now very close.
>
> Very warm regards,
> David
>
> On 13/11/2013 03:54, Mark Kirkwood wrote:
>> On 13/11/13 16:33, Mark Kirkwood wrote:
>>> On 13/11/13 04:53, Alfredo Deza wrote:
>>>> On Mon, Nov 11, 2013 at 12:51 PM, Dave (Bob)
>>>> <dave@bob-the-boat.me.uk> wrote:
>>>>
>>>>> It is unuseable for me at present, because it reports:
>>>>>
>>>>> [ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported:
>>>>>
>>>> That looks like a bug. For the past few months the log output of
>>>> ceph-deploy has tried to improve to give as much useful information
>>>> as possible.
>>>>
>>>> To get to the bottom of this it would be super helpful to know what
>>>> distro you were attempting to connect to, what the actual command was,
>>>> and what version of ceph-deploy you were using.
>>>>
>>>> Hopefully, with that information and the (possible) bug fix, it will
>>>> mean that more and more people find ceph-deploy as a robust solution
>>>> to get
>>>> a Ceph cluster up and running.
>>>>
>>>>
>>>
>>> I believe he is using a self built (or heavily customized) Linux
>>> installation - so distribution detection is not going to work in this
>>> case. I'm wondering if there could be some sensible fall back for
>>> that, e.g:
>>>
>>> - refuse to install or purge
>>> - assume sysv init
>>>
>>> so that ceph-deploy can 'do the best it can' in these situations.
>>> Thoughts?
>>>
>>
>> Ahem - replying to myself, sorry:
>>
>> It might be just as easy to allow init to be specified as an option
>> (--init INITTYPE). As an aside, for my development (Ubuntu)
>> workstation, I'm building ceph from src and using ceph-deploy to
>> install it - *but* am switching init to sysv afterwards (I just prefer
>> to use it for that situation).
>>
>> Cheers
>>
>> Mark
>>
>>
>
> --
> 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
>

Re: Mourning the demise of mkcephfs

[Mark Kirkwood]

On 15/11/13 03:25, Mark Nelson wrote:
> On 11/14/2013 06:27 AM, Dave (Bob) wrote:
>> I would suggest that it is always dangerous to make assumptions.
>> If ceph-deploy needs some information, then this should be explicit, and
>> configurable.
>> If it needs to know whether initialisation is done by systemd, upstart,
>> or sysv init, then what is wrong with requesting a config option?
>>
>> As it happens, ceph-deploy doesn't seem to be what I require as a
>> mkcephfs replacement.
>> An earlier exchange with Mark suggests that it wants to involve itself
>> with the installation of software, and the configuration of startup
>> mechanisms.
>
> I am not an expert on ceph-deploy by any means.  ceph-deploy can do 
> these thing (install software, startup, etc), but I don't think it 
> strictly has to.
>
>> This is not what I want, and it is not any part of what mkcephfs did.
>>
>> Given that I have ceph installed, and a bunch of disk drives, I need to
>> be able to drive the ceph applications appropriately to set up the
>> osd's, keys, and other required data so that I can start the
>> ceph-osd(s), the ceph-mon(s), and the ceph-mds(s) [which I can do by
>> typing! (and I can make systemd do it automatically if and when I find
>> that I'm ready for that)].
>>
>> This is what mkcephfs did.
>>

As Mark said, you can do that with ceph-deploy.  It *will* try to start 
the mon(s) and osd(s), but that is not usually a problem. I use 
ceph-deploy on systems where I've built ceph from source with no 
problems (actually once you get used to it, ceph-deploy is really very 
easy to use, and I *now* find it more convenient than mkcephfs ever was).

Cheers

Mark

Could ceph-deploy handle unknown or custom distribution? (Was: Mourning the demise of mkcephfs)

[Mark Kirkwood]

[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]

On 13/11/13 16:33, Mark Kirkwood wrote:
> I believe he is using a self built (or heavily customized) Linux
> installation - so distribution detection is not going to work in this
> case. I'm wondering if there could be some sensible fall back for that,
> e.g:
>
> - refuse to install or purge
> - assume sysv init
>

It was raining here on Saturday so I thought I'd take a look at if this 
was even feasible (see attached). These patches are a rough experiment 
to see what *might* be involved in getting to a point where you could 
get a system going on one of the distributions (or a custom build) that 
we currently do not support. So view as a thought-in-progress rather 
than even wip :-) It could also be quite the wrong approach - that is 
ok, just let me know what you think. Hopefully even if it is wrong, it 
may help stimulate discussion (or patches) for how to do it right!

The 1st patch defines an 'unknown' distribution for cases where one of 
our well known cases is *not* detected. With it applied I can create 
mons and it will start them directly with ceph-mon.

The 2nd and 3rd patch do similarly for osd, defining a type of startup 
called 'direct' to mark the osd instance with. I needed to patch 
ceph-disk as well so it could start the resulting osd directly with 
ceph-osd, and add it into the crushmap at a (hopefully) sensible place.

(BTW I did want to do this all in ceph-deploy, but right now it does not 
know how to get an osd's id number from a disk device - mind you this 
could be useful to add for things like 'list' and 'destroy'... but I 
digress).

Anyway I have attached a log of me getting a system of 2 Archlinux nodes 
up. These were KVM guests built identically and ceph (0.72) was compiled 
from src and installed.

Cheers

Mark




[-- Attachment #2: ceph-deploy-unknown-0.patch --]
[-- Type: text/x-patch, Size: 3563 bytes --]

commit 0629a803d7a1ecb651ed34c402c41f72bafaec7d
Author: Mark Kirkwood <mark.kirkwood@gmail.com>
Date:   Sun Nov 17 00:43:20 2013 +1300

    Initial prototype for handling unknown distribution types.

diff --git a/ceph_deploy/hosts/__init__.py b/ceph_deploy/hosts/__init__.py
index f4ba203..8f6a541 100644
--- a/ceph_deploy/hosts/__init__.py
+++ b/ceph_deploy/hosts/__init__.py
@@ -6,7 +6,7 @@ on the type of distribution/version we are dealing with.
 """
 import logging
 from ceph_deploy import exc, lsb
-from ceph_deploy.hosts import debian, centos, fedora, suse, remotes
+from ceph_deploy.hosts import debian, centos, fedora, suse, remotes, unknown
 from ceph_deploy.connection import get_connection
 
 logger = logging.getLogger()
@@ -62,6 +62,7 @@ def _get_distro(distro, fallback=None):
         'redhat': centos,
         'fedora': fedora,
         'suse': suse,
+        'unknown': unknown,
         }
     try:
         return distributions[distro]
@@ -79,4 +80,6 @@ def _normalized_distro_name(distro):
         return 'scientific'
     elif distro.startswith(('suse', 'opensuse')):
         return 'suse'
+    elif distro.startswith('unknown'):
+        return 'unknown'
     return distro
diff --git a/ceph_deploy/hosts/remotes.py b/ceph_deploy/hosts/remotes.py
index 62766f7..c759982 100644
--- a/ceph_deploy/hosts/remotes.py
+++ b/ceph_deploy/hosts/remotes.py
@@ -18,10 +18,21 @@ def platform_information():
         major_version = release.split('.')[0]
         codename = debian_codenames.get(major_version, '')
 
+    distro = str(distro).rstrip(),
+    distro = str(release).rstrip(),
+    distro = str(codename).rstrip()
+
+    if distro == '':
+        distro = 'unknown'
+    if release == '':
+        release = 'unknown'
+    if codename == '':
+        codename = 'unknown'
+
     return (
-        str(distro).rstrip(),
-        str(release).rstrip(),
-        str(codename).rstrip()
+        str(distro),
+        str(release),
+        str(codename)
     )
 
 
diff --git a/ceph_deploy/hosts/unknown/__init__.py b/ceph_deploy/hosts/unknown/__init__.py
new file mode 100644
index 0000000..d67ad7e
--- /dev/null
+++ b/ceph_deploy/hosts/unknown/__init__.py
@@ -0,0 +1,8 @@
+import mon
+
+# Allow to set some information about this distro
+#
+
+distro = None
+release = None
+codename = None
diff --git a/ceph_deploy/hosts/unknown/mon/__init__.py b/ceph_deploy/hosts/unknown/mon/__init__.py
new file mode 100644
index 0000000..fca0e0d
--- /dev/null
+++ b/ceph_deploy/hosts/unknown/mon/__init__.py
@@ -0,0 +1 @@
+from create import create
diff --git a/ceph_deploy/hosts/unknown/mon/create.py b/ceph_deploy/hosts/unknown/mon/create.py
new file mode 100644
index 0000000..ed2a3ba
--- /dev/null
+++ b/ceph_deploy/hosts/unknown/mon/create.py
@@ -0,0 +1,30 @@
+from ceph_deploy.hosts import common
+from ceph_deploy.lib.remoto import process
+
+
+def create(distro, args, monitor_keyring):
+    hostname = distro.conn.remote_module.shortname()
+    common.mon_create(distro, args, monitor_keyring, hostname)
+
+    # no idea about startup architecture so start directly, run + create keys
+    process.run(
+        distro.conn,
+        [
+            'ceph-mon',
+            '--cluster', args.cluster,
+            '-c', '/etc/ceph/{cluster}.conf'.format(cluster=args.cluster),
+            '-i', hostname,
+        ],
+        timeout=7,
+    )
+
+    process.run(
+        distro.conn,
+        [
+            'ceph-create-keys',
+            '--cluster', args.cluster,
+            '-i', hostname,
+        ],
+        timeout=7,
+    )
+

[-- Attachment #3: ceph-deploy-unknown-1.patch --]
[-- Type: text/x-patch, Size: 331 bytes --]

diff --git a/ceph_deploy/lsb.py b/ceph_deploy/lsb.py
index b7f3e73..2f608de 100644
--- a/ceph_deploy/lsb.py
+++ b/ceph_deploy/lsb.py
@@ -118,4 +118,6 @@ def choose_init(distro, codename):
     """
     if distro == 'Ubuntu':
         return 'upstart'
+    elif  distro == 'unknown':
+        return 'direct'
     return 'sysvinit'

[-- Attachment #4: ceph-disk-unknown-0.patch --]
[-- Type: text/x-patch, Size: 2321 bytes --]

*** ceph-disk.orig	Sun Nov 17 11:34:33 2013
--- ceph-disk	Mon Nov 18 13:21:20 2013
***************
*** 96,101 ****
--- 96,102 ----
      'upstart',
      'sysvinit',
      'systemd',
+     'direct',
      'auto',
      ]
  
***************
*** 1438,1443 ****
--- 1439,1470 ----
                      'osd.{osd_id}'.format(osd_id=osd_id),
                      ],
                  )
+         elif os.path.exists(os.path.join(path, 'direct')):
+             # no idea about which init, start directly and set crush location
+             subprocess.check_call(
+                 args=[
+                     '/usr/bin/ceph-osd',
+                     #'--cluster', args.cluster,
+                     #'-c', '/etc/ceph/{cluster}.conf'.format(cluster=args.cluster),
+                     '-i', '{osd_id}'.format(osd_id=osd_id),
+                     ],
+                 )
+ 
+             # assume weight 1 (wrong but easy to change)!
+             subprocess.check_call(
+                 args=[
+                     '/usr/bin/ceph',
+                     #'--cluster', args.cluster,
+                     #'-c', '/etc/ceph/{cluster}.conf'.format(cluster=args.cluster),
+                     'osd',
+                     'crush',
+                      'add',
+                     'osd.{osd_id}'.format(osd_id=osd_id),
+                     '1',
+                     'root=default',
+                     'host={hostname}'.format(hostname=platform.node()),
+                     ],
+                 )
          else:
              raise Error('{cluster} osd.{osd_id} is not tagged with an init system'.format(
                      cluster=cluster,
***************
*** 1683,1690 ****
--- 1710,1722 ----
                      (distro, release, codename) = platform.dist()
                      if distro == 'Ubuntu':
                          init = 'upstart'
+                     if distro == 'unknown' or distro == '':
+                         LOG.debug('distro is empty, assuming init is direct')
+                         init = 'direct'
                      else:
                          init = 'sysvinit'
+             if init == 'direct':
+                 LOG.debug('init is direct')
  
              LOG.debug('Marking with init system %s', init)
              with file(os.path.join(path, init), 'w'):

[-- Attachment #5: NOTES-unknown --]
[-- Type: text/plain, Size: 1650 bytes --]

After applying patch for unknown distro
=======================================

State:

- monitors created and start ok
- osd created ok
  * not started (startup by ceph-disk)
  * no crush setting (set by init scripts)

Test on Archlinux hosts (zor[2,3]), running ceph-deploy from Ubuntu workstation 
(localhost)


1/ Do src build installing binaries and udev:

(zor2) $ sudo make install
(zor2) $ sudo cp udev/* /lib/udev/rules.d/
(zor2) $ cd /var/lib/ceph;sudo mkdir bootstrap-mds bootstrap-osd mds mon osd tmp
(zor2) $ sudo mkdir /etc/ceph

[same for zor3]


2/ Deploy with (patched) ceph-deploy 

(localhost) $ ceph-deploy new zor2
(localhost) $ ceph-deploy mon create zor2
(localhost) $ ceph-deploy gatherkeys zor2
(localhost) $ ceph-deploy disk zap zor2:/dev/vdb
(localhost) $ ceph-deploy disk zap zor3:/dev/vdb
(localhost) $ ceph-deploy osd prepare zor2:/dev/vdb
(localhost) $ ceph-deploy osd prepare zor3:/dev/vdb
(localhost) $ ceph-deploy osd activate zor2:/dev/vdb1
(localhost) $ ceph-deploy osd activate zor3:/dev/vdb1


3/ Check state

(localhost) $ ceph -c ceph.conf -k ceph.client.admin.keyring -s
    cluster de5d8fac-58b1-411a-8047-dd46d0d91246
     health HEALTH_OK
     monmap e1: 1 mons at {zor2=192.168.122.12:6789/0}, election epoch 2, quorum 0 zor2
     osdmap e36: 2 osds: 2 up, 2 in
      pgmap v55: 192 pgs, 3 pools, 0 bytes data, 0 objects
            70852 kB used, 6052 MB / 6121 MB avail
                 192 active+clean

(localhost) $ ceph -c ceph.conf -k ceph.client.admin.keyring osd tree
# id	weight	type name	up/down	reweight
-1	2	root default
-2	1		host zor3
1	1			osd.1	up	1	
-3	1		host zor2
0	1			osd.0	up	1	

Re: Could ceph-deploy handle unknown or custom distribution? (Was: Mourning the demise of mkcephfs)

[Mark Kirkwood]

On 18/11/13 19:05, Mark Kirkwood wrote:

> Anyway I have attached a log of me getting a system of 2 Archlinux nodes
> up. These were KVM guests built identically and ceph (0.72) was compiled
> from src and installed.
>

Blast - forgot to edit the top of the log to reflect the effect of the 
osd and ceph-disk patches, should say:

State:

- monitors created and start ok
- osd created ok
- osd started ok via 'activate' after patching ceph-disk