Ceph

I'm not sure this is a good idea? My impression was that the binaries shipped in the ceph-test RPM are primarily used in testing.

Vikhyat, can you elaborate the rationale for this proposal?

Nathan Cutler wrote:

I'm not sure this is a good idea? My impression was that the binaries shipped in the ceph-test RPM are primarily used in testing.

Vikhyat, can you elaborate the rationale for this proposal?

Hi Nathan,

Thanks for the feedback I just checked the rpm -ql and yes it has test binaries also:

# rpm -ql ceph-test
/usr/bin/ceph-coverage
/usr/bin/ceph-debugpack
/usr/bin/ceph-kvstore-tool
/usr/bin/ceph-monstore-tool
/usr/bin/ceph-osdomap-tool
/usr/bin/ceph_bench_log
/usr/bin/ceph_erasure_code
/usr/bin/ceph_erasure_code_benchmark
/usr/bin/ceph_kvstorebench
/usr/bin/ceph_multi_stress_watch
/usr/bin/ceph_objectstore_bench
/usr/bin/ceph_omapbench
/usr/bin/ceph_perf_local
/usr/bin/ceph_perf_msgr_client
/usr/bin/ceph_perf_msgr_server
/usr/bin/ceph_perf_objectstore
/usr/bin/ceph_psim
/usr/bin/ceph_radosacl
/usr/bin/ceph_rgw_jsonparser
/usr/bin/ceph_rgw_multiparser
/usr/bin/ceph_scratchtool
/usr/bin/ceph_scratchtoolpp
/usr/bin/ceph_smalliobench
/usr/bin/ceph_smalliobenchdumb
/usr/bin/ceph_smalliobenchfs
/usr/bin/ceph_smalliobenchrbd
/usr/bin/ceph_test_async_driver
/usr/bin/ceph_test_c_headers
/usr/bin/ceph_test_cfuse_cache_invalidate
/usr/bin/ceph_test_cls_hello
/usr/bin/ceph_test_cls_journal
/usr/bin/ceph_test_cls_lock
/usr/bin/ceph_test_cls_log
/usr/bin/ceph_test_cls_numops
/usr/bin/ceph_test_cls_rbd
/usr/bin/ceph_test_cls_refcount
/usr/bin/ceph_test_cls_replica_log
/usr/bin/ceph_test_cls_rgw
/usr/bin/ceph_test_cls_rgw_log
/usr/bin/ceph_test_cls_rgw_meta
/usr/bin/ceph_test_cls_rgw_opstate
/usr/bin/ceph_test_cls_statelog
/usr/bin/ceph_test_cls_version
/usr/bin/ceph_test_cors
/usr/bin/ceph_test_crypto
/usr/bin/ceph_test_filejournal
/usr/bin/ceph_test_filestore
/usr/bin/ceph_test_filestore_idempotent
/usr/bin/ceph_test_filestore_idempotent_sequence
/usr/bin/ceph_test_get_blkdev_size
/usr/bin/ceph_test_ioctls
/usr/bin/ceph_test_keys
/usr/bin/ceph_test_keyvaluedb
/usr/bin/ceph_test_keyvaluedb_atomicity
/usr/bin/ceph_test_keyvaluedb_iterators
/usr/bin/ceph_test_libcephfs
/usr/bin/ceph_test_librbd
/usr/bin/ceph_test_librbd_api
/usr/bin/ceph_test_librbd_fsx
/usr/bin/ceph_test_mon_msg
/usr/bin/ceph_test_mon_workloadgen
/usr/bin/ceph_test_msgr
/usr/bin/ceph_test_mutate
/usr/bin/ceph_test_object_map
/usr/bin/ceph_test_objectcacher_stress
/usr/bin/ceph_test_objectstore
/usr/bin/ceph_test_objectstore_workloadgen
/usr/bin/ceph_test_rados
/usr/bin/ceph_test_rados_api_aio
/usr/bin/ceph_test_rados_api_c_read_operations
/usr/bin/ceph_test_rados_api_c_write_operations
/usr/bin/ceph_test_rados_api_cls
/usr/bin/ceph_test_rados_api_cmd
/usr/bin/ceph_test_rados_api_io
/usr/bin/ceph_test_rados_api_list
/usr/bin/ceph_test_rados_api_lock
/usr/bin/ceph_test_rados_api_misc
/usr/bin/ceph_test_rados_api_nlist
/usr/bin/ceph_test_rados_api_pool
/usr/bin/ceph_test_rados_api_snapshots
/usr/bin/ceph_test_rados_api_stat
/usr/bin/ceph_test_rados_api_tier
/usr/bin/ceph_test_rados_api_tmap_migrate
/usr/bin/ceph_test_rados_api_watch_notify
/usr/bin/ceph_test_rados_delete_pools_parallel
/usr/bin/ceph_test_rados_list_parallel
/usr/bin/ceph_test_rados_open_pools_parallel
/usr/bin/ceph_test_rados_watch_notify
/usr/bin/ceph_test_rbd_mirror
/usr/bin/ceph_test_rbd_mirror_random_write
/usr/bin/ceph_test_rewrite_latency
/usr/bin/ceph_test_rgw_manifest
/usr/bin/ceph_test_rgw_obj
/usr/bin/ceph_test_rgw_period_history
/usr/bin/ceph_test_signal_handlers
/usr/bin/ceph_test_snap_mapper
/usr/bin/ceph_test_stress_watch
/usr/bin/ceph_test_timers
/usr/bin/ceph_test_trans
/usr/bin/ceph_tpbench
/usr/bin/ceph_xattr_bench
/usr/bin/librgw_file
/usr/bin/librgw_file_aw
/usr/bin/librgw_file_cd
/usr/bin/librgw_file_gp
/usr/bin/librgw_file_nfsns
/usr/lib64/ceph
/usr/lib64/ceph/ceph-monstore-update-crush.sh

We mostly install this package in production cluster to use these three tools:

/usr/bin/ceph-kvstore-tool
/usr/bin/ceph-monstore-tool
/usr/bin/ceph-osdomap-tool

I think I will change this Feature request to package these three tools to respective packages.

For example ceph-monstore-tool in ceph-mon package and ceph-kvstore-tool in ceph-mon and ceph-osd and ceph-osdomap-tool to ceph-osd package.

This will help us to remove these tools from ceph-test package and then the respective Ceph daemon package will have the tools which are needed for troubleshooting issues.

If these daemon packages are becoming heavier we can create a new package ceph-tools where we can have all tools used in Ceph.

Vikhyat Umrao wrote:

If these daemon packages are becoming heavier we can create a new package ceph-tools where we can have all tools used in Ceph.

The ceph-test package can indeed be extremely "heavy" especially if just to install those three ceph-*-tool binaries.

I would be in favor of putting those three into a separate "ceph-tools" package.

Add ceph-monstore-tool in ceph-mon package, ceph-kvstore-tool in ceph-mon and ceph-osd, and ceph-osdomap-tool in ceph-osd package.

This is even better :-)

ceph-kvstore-tool in ceph-mon and ceph-osd

Oh, wait. This is unfortunately not possible. A single file (ceph-kvstore-tool in this case) can only be owned by a single subpackage.

If it's absolutely necessary to have ceph-kvstore-tool on both OSD and MON nodes, then it would need to be placed (by itself) into a separate "ceph-kvstore-tool" subpackage that the ceph-osd and ceph-mon subpackages could then require.

Thanks, Nathan sounds great!

What do you think about putting ceph-kvstore-tool into the ceph-base instead of introducing a new sub-package just for that?

Then it (ceph-kvstore-tool) will be included with ceph-mds and ceph-mgr as well, but I guess that's not a problem. Updating the PR.

Yeah, I'm ok with that trade-off, particularly since the -mgr will likely already be on a monitor node.