Re: [ceph-users] removing 'rados cppool' command

2016-05-07 Thread 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
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com


Re: [ceph-users] removing 'rados cppool' command

2016-05-06 Thread Yehuda Sadeh-Weinraub
On Fri, May 6, 2016 at 2:27 PM, Sage Weil  wrote:
> On Fri, 6 May 2016, Yehuda Sadeh-Weinraub wrote:
>> On Fri, May 6, 2016 at 12:41 PM, 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.
>> >
>> > 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
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com


Re: [ceph-users] removing 'rados cppool' command

2016-05-06 Thread Sage Weil
On Fri, 6 May 2016, Yehuda Sadeh-Weinraub wrote:
> On Fri, May 6, 2016 at 12:41 PM, 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.
> >
> > 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
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com


Re: [ceph-users] removing 'rados cppool' command

2016-05-06 Thread Yehuda Sadeh-Weinraub
On Fri, May 6, 2016 at 12:41 PM, 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.
>
> 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
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com