removing 'rados cppool' command

removing 'rados cppool' command

[Sage Weil]

This PR

	https://github.com/ceph/ceph/pull/8975

removes the 'rados cppool' command.  The main problem is that the command 
does not make a faithful copy of all data because it doesn't preserve the 
snapshots (and snapshot related metadata).  That means if you copy an RBD 
pool it will render the images somewhat broken (snaps won't be present and 
won't work properly).  It also doesn't preserve the user_version field 
that some librados users may rely on.

Since it's obscure and of limited use, this PR just removes it.

Alternatively, we could add safeguards so that it refuses to make a copy 
if there are any selfmanaged_snaps, and/or generate some warnings.  

Any objections?
sage

Re: removing 'rados cppool' command

[Yehuda Sadeh-Weinraub]

On Fri, May 6, 2016 at 12:41 PM, Sage Weil <sweil-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> This PR
>
>         https://github.com/ceph/ceph/pull/8975
>
> removes the 'rados cppool' command.  The main problem is that the command
> does not make a faithful copy of all data because it doesn't preserve the
> snapshots (and snapshot related metadata).  That means if you copy an RBD
> pool it will render the images somewhat broken (snaps won't be present and
> won't work properly).  It also doesn't preserve the user_version field
> that some librados users may rely on.
>
> Since it's obscure and of limited use, this PR just removes it.
>
> Alternatively, we could add safeguards so that it refuses to make a copy
> if there are any selfmanaged_snaps, and/or generate some warnings.
>
> Any objections?

I prefer the alternative. I found this command pretty useful for
testing config upgrade scenarios with rgw. After generating config
scenarios in older versions, I used this command to store the config
on another pool, and then I could get the different config whenever
needed.

Yehuda

Re: removing 'rados cppool' command

[Sage Weil]

On Fri, 6 May 2016, Yehuda Sadeh-Weinraub wrote:
> On Fri, May 6, 2016 at 12:41 PM, Sage Weil <sweil@redhat.com> wrote:
> > This PR
> >
> >         https://github.com/ceph/ceph/pull/8975
> >
> > removes the 'rados cppool' command.  The main problem is that the command
> > does not make a faithful copy of all data because it doesn't preserve the
> > snapshots (and snapshot related metadata).  That means if you copy an RBD
> > pool it will render the images somewhat broken (snaps won't be present and
> > won't work properly).  It also doesn't preserve the user_version field
> > that some librados users may rely on.
> >
> > Since it's obscure and of limited use, this PR just removes it.
> >
> > Alternatively, we could add safeguards so that it refuses to make a copy
> > if there are any selfmanaged_snaps, and/or generate some warnings.
> >
> > Any objections?
> 
> I prefer the alternative. I found this command pretty useful for
> testing config upgrade scenarios with rgw. After generating config
> scenarios in older versions, I used this command to store the config
> on another pool, and then I could get the different config whenever
> needed.

Keep in mind that all of these calls in rgw

	rgw/rgw_rados.cc:  epoch = ref.ioctx.get_last_version();

may be subtley broken by cppool because user_version is not preserved...

sage

Re: removing 'rados cppool' command

[Yehuda Sadeh-Weinraub]

On Fri, May 6, 2016 at 2:27 PM, Sage Weil <sweil@redhat.com> wrote:
> On Fri, 6 May 2016, Yehuda Sadeh-Weinraub wrote:
>> On Fri, May 6, 2016 at 12:41 PM, Sage Weil <sweil@redhat.com> wrote:
>> > This PR
>> >
>> >         https://github.com/ceph/ceph/pull/8975
>> >
>> > removes the 'rados cppool' command.  The main problem is that the command
>> > does not make a faithful copy of all data because it doesn't preserve the
>> > snapshots (and snapshot related metadata).  That means if you copy an RBD
>> > pool it will render the images somewhat broken (snaps won't be present and
>> > won't work properly).  It also doesn't preserve the user_version field
>> > that some librados users may rely on.
>> >
>> > Since it's obscure and of limited use, this PR just removes it.
>> >
>> > Alternatively, we could add safeguards so that it refuses to make a copy
>> > if there are any selfmanaged_snaps, and/or generate some warnings.
>> >
>> > Any objections?
>>
>> I prefer the alternative. I found this command pretty useful for
>> testing config upgrade scenarios with rgw. After generating config
>> scenarios in older versions, I used this command to store the config
>> on another pool, and then I could get the different config whenever
>> needed.
>
> Keep in mind that all of these calls in rgw
>
>         rgw/rgw_rados.cc:  epoch = ref.ioctx.get_last_version();
>
> may be subtley broken by cppool because user_version is not preserved...
>

Right, but these calls are done in the bucket index pool, not at the
root or metadata pools that are relevant to the system config. While
it may not be the perfect tool for everything, I still find it useful
from time to time.

Yehuda

Re: removing 'rados cppool' command

[Mykola Golub]

On Fri, May 06, 2016 at 03:41:34PM -0400, Sage Weil wrote:
> This PR
> 
> 	https://github.com/ceph/ceph/pull/8975
> 
> removes the 'rados cppool' command.  The main problem is that the command 
> does not make a faithful copy of all data because it doesn't preserve the 
> snapshots (and snapshot related metadata).  That means if you copy an RBD 
> pool it will render the images somewhat broken (snaps won't be present and 
> won't work properly).  It also doesn't preserve the user_version field 
> that some librados users may rely on.
> 
> Since it's obscure and of limited use, this PR just removes it.

Copying a pool sometimes is useful, even with those limitations.

Until there is an alternative way to do the same I would not remove
this. A better approach to me is to move this functionality to
something like `ceph_radostool` (people use such tools only when
facing extraordinary situations so they are more careful and expect
limitations).

-- 
Mykola Golub