Bug #19577
closedship radosgw-admin in ceph-common package
0%
Description
Since radosgw-admin requires admin keys to operate, it makes sense to ship this with client packages so that it can be used for admin related operations
Related to:
https://github.com/ceph/ceph-ansible/issues/1351
$ ldd /usr/bin/radosgw-admin linux-vdso.so.1 => (0x00007ffd6eb8d000) librgw.so.2 => /lib64/librgw.so.2 (0x00007f9c0c5df000) librados.so.2 => /lib64/librados.so.2 (0x00007f9c02e5e000) libboost_system-mt.so.1.53.0 => /lib64/libboost_system-mt.so.1.53.0 (0x00007f9c02c59000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9c02a3d000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f9c02735000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f9c0251e000) libc.so.6 => /lib64/libc.so.6 (0x00007f9c0215d000) libssl3.so => /lib64/libssl3.so (0x00007f9c01f1a000) libsmime3.so => /lib64/libsmime3.so (0x00007f9c01cf2000) libnss3.so => /lib64/libnss3.so (0x00007f9c019cc000) libnssutil3.so => /lib64/libnssutil3.so (0x00007f9c017a0000) libplds4.so => /lib64/libplds4.so (0x00007f9c0159b000) libplc4.so => /lib64/libplc4.so (0x00007f9c01396000) libnspr4.so => /lib64/libnspr4.so (0x00007f9c01158000) libcurl.so.4 => /lib64/libcurl.so.4 (0x00007f9c00eee000) libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f9c00cc4000) libfcgi.so.0 => /lib64/libfcgi.so.0 (0x00007f9c00ab9000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f9c0089e000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f9c0069a000) libboost_thread-mt.so.1.53.0 => /lib64/libboost_thread-mt.so.1.53.0 (0x00007f9c00483000) libboost_random-mt.so.1.53.0 => /lib64/libboost_random-mt.so.1.53.0 (0x00007f9c0027e000) libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f9c00040000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f9bffe3b000) librt.so.1 => /lib64/librt.so.1 (0x00007f9bffc32000) libboost_iostreams-mt.so.1.53.0 => /lib64/libboost_iostreams-mt.so.1.53.0 (0x00007f9bffa18000) libm.so.6 => /lib64/libm.so.6 (0x00007f9bff716000) /lib64/ld-linux-x86-64.so.2 (0x00007f9c164c8000) libz.so.1 => /lib64/libz.so.1 (0x00007f9bff4ff000) libidn.so.11 => /lib64/libidn.so.11 (0x00007f9bff2cb000) libssh2.so.1 => /lib64/libssh2.so.1 (0x00007f9bff0a1000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f9bfee53000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f9bfeb6b000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f9bfe939000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f9bfe735000) liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f9bfe525000) libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007f9bfe2d2000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f9bfe0b9000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f9bfdea8000) libssl.so.10 => /lib64/libssl.so.10 (0x00007f9bfdc3a000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f9bfd84f000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f9bfd640000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f9bfd43c000) libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f9bfd21e000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f9bfcff7000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f9bfcdbf000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f9bfcb5e000) libfreebl3.so => /lib64/libfreebl3.so (0x00007f9bfc95b000)
Updated by Ken Dreyer about 7 years ago
The original GitHub ticket mentioned ceph-common
- what do you think about shipping it there?
Updated by Vasu Kulkarni about 7 years ago
Ken, yeah sorry for the confusion, correct it shoould be ceph-common and can be used on any monitor node.
Updated by Ken Dreyer about 7 years ago
- Subject changed from ship radosgw-admin with ceph-mon to ship radosgw-admin in ceph-common package
- Description updated (diff)
Updated by Ken Dreyer about 7 years ago
- Backport deleted (
jewel, kraken)
Ali and I discussed this, and it would be better to not backport this to jewel.
Updated by Ali Maredia about 7 years ago
Ken Dreyer wrote:
Ali and I discussed this, and it would be better to not backport this to jewel.
Here are some quick reasons in the discussion we had:
1. I don't want to give the users (especially those new to Ceph) the impression that the radosgw-admin command works without a running radosgw
2. Would someone have to test that the radosgw-admin command works on all client nodes before every release?
3. I don't like moving files around packages, especially in the middle of a stable release
At the end of the day I feel like the benefit isn't as much as the cost. Is there really a reason why the keys shouldn't be on rgw nodes? If the packages is in ceph-common and users run radosgw-admin commands from the rgw nodes then doesn't that defeat the purpose of moving the package? Is there really a benefit of running radosgw-admin from non-rgw client nodes?
Updated by Vasu Kulkarni about 7 years ago
My comments...
1. I don't want to give the users (especially those new to Ceph) the impression that the radosgw-admin command works without a running radosgw
This would be a improvement bug for radosg-admin, that can verify if the daemon is running or not
2. Would someone have to test that the radosgw-admin command works on all client nodes before every release?
I think the original idea was to get this into monitor nodes, we are not going to run this on client, the ceph-common was a way to get this in monitor node
which we use for various admin activities
Updated by Ken Dreyer almost 7 years ago
- Status changed from New to Fix Under Review
Updated by Ali Maredia almost 7 years ago
- Status changed from Fix Under Review to Resolved