On Fri, Mar 24, 2017 at 6:49 PM, nokia ceph <nokiacephus...@gmail.com> wrote:
> Brad, cool now we are on the same track :)
>
> So whatever change we made after this location src/* as it mapped to
> respective rpm correct?
>
> For eg:-
> src/osd/* -- ceph-osd
> src/common - ceph-common
> src/mon - ceph-mon
> src/mgr - ceph-mgr
I think this is true in most, if not all, cases.
>
> Since we are using bluestore with kraken, I though to disable the below
> warning while triggering `ceph -s`
>
> ~~~
> WARNING: the following dangerous and experimental features are enabled:
> ~~~
Can I ask why you want to disable this warning?
>
> Here I made a comment in this file
>
>>vim src/common/ceph_context.cc
> 307 // if (!cct->_experimental_features.empty())
> 308 // lderr(cct) << "WARNING: the following dangerous and experimental
> features are enabled: "
> 309 // << cct->_experimental_features << dendl;
Right.
>
> As per my assumption, the change should reflect in this binary
> "ceph-common"
libceph-common specifically.
>
> But when I closely looked on librados library as these warning showing here
> also.
> #strings -a /usr/lib64/librados.so.2 | grep dangerous
> WARNING: the following dangerous and experimental features are enabled: -->
>
> Then I conclude for this change ceph-common and librados were required.
>
> Please correct me if I'm wrong.
So I looked at this on current master built on Fedora and see the following.
$ for lib in $(find . \! -type l -type f -name lib\*); do strings $lib|grep
"following dangerous and experimenta l"; if [ $? -eq 0 ]; then echo $lib; fi;
done
WARNING: the following dangerous and experimental features are enabled:
./libcephd.a
WARNING: the following dangerous and experimental features are enabled:
./libceph-common.so.0
WARNING: the following dangerous and experimental features are enabled:
./libcommon.a
So in my case the only shared object that has this string is libceph-common.
However, that library is dynamically linked to libceph-common.
$ ldd librados.so.2.0.0|grep libceph-common
libceph-common.so.0 =>
/home/brad/working/src/ceph/build/lib/libceph-common.so.0 (0x00007faa2cf42000)
I checked a rhel version and sure enough the string is there, because in that
version on rhel/CentOS we statically linked libcommon.a into librados IIRC.
# ldd librados.so.2.0.0|grep libceph-common
#
So if the string shows up in your librados then I'd suggest it is also
statically linked ([1] we only changed this fairly recently) and you will need
to replace it to reflect your change.
[1] https://github.com/ceph/ceph/commit/8f7643792c9e6a3d1ba4a06ca7d09b0de9af1443
>
> On Fri, Mar 24, 2017 at 5:41 AM, Brad Hubbard <bhubb...@redhat.com> wrote:
>>
>> Oh wow, I completely misunderstood your question.
>>
>> Yes, src/osd/PG.cc and src/osd/PG.h are compiled into the ceph-osd binary
>> which
>> is included in the ceph-osd rpm as you said in your OP.
>>
>> On Fri, Mar 24, 2017 at 3:10 AM, nokia ceph <nokiacephus...@gmail.com>
>> wrote:
>> > Hello Piotr,
>> >
>> > I didn't understand, could you please elaborate about this procedure as
>> > mentioned in the last update. It would be really helpful if you share
>> > any
>> > useful link/doc to understand what you actually meant. Yea correct,
>> > normally
>> > we do this procedure but it takes more time. But here my intention is to
>> > how
>> > to find out the rpm which caused the change. I think we are in opposite
>> > direction.
>> >
>> >>> But wouldn't be faster and/or more convenient if you would just
>> >>> recompile
>> >>> binaries in-place (or use network symlinks)
>> >
>> > Thanks
>> >
>> >
>> >
>> > On Thu, Mar 23, 2017 at 6:47 PM, Piotr Dałek <piotr.da...@corp.ovh.com>
>> > wrote:
>> >>
>> >> On 03/23/2017 02:02 PM, nokia ceph wrote:
>> >>
>> >>> Hello Piotr,
>> >>>
>> >>> We do customizing ceph code for our testing purpose. It's a part of
>> >>> our
>> >>> R&D :)
>> >>>
>> >>> Recompiling source code will create 38 rpm's out of these I need to
>> >>> find
>> >>> which one is the correct rpm which I made change in the source code.
>> >>> That's
>> >>> what I'm try to figure out.
>> >>
>> >>
>> >> Yes, I understand that. But wouldn't be faster and/or more convenient
>> >> if
>> >> you would just recompile binaries in-place (or use network symlinks)
>> >> instead
>> >> of packaging entire Ceph and (re)installing its packages each time you
>> >> do
>> >> the change? Generating RPMs takes a while.
>> >>
>> >>
>> >> --
>> >> Piotr Dałek
>> >> piotr.da...@corp.ovh.com
>> >> https://www.ovh.com/us/
>> >
>> >
>> >
>> > _______________________________________________
>> > ceph-users mailing list
>> > ceph-users@lists.ceph.com
>> > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
>> >
>>
>>
>>
>> --
>> Cheers,
>> Brad
>
>
--
Cheers,
Brad
_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
