[Gluster-users] [Gluster-devel] Dependency issue while installing glusterfs-3.6beta with vdsm

[Humble Chirammal]

On 10/31/2014 03:46 AM, Anders Blomdell wrote:
> On 2014-10-30 22:44, Anders Blomdell wrote:
>> On 2014-10-30 22:06, Kaleb KEITHLEY wrote:
>>> On 10/30/2014 04:34 PM, Anders Blomdell wrote:
>>>> On 2014-10-30 20:55, Kaleb KEITHLEY wrote:
>>>>> On 10/30/2014 01:50 PM, Anders Blomdell wrote:
>>>>>> On 2014-10-30 14:52, Kaleb KEITHLEY wrote:
>>>>>>> On 10/30/2014 04:36 AM, Anders Blomdell wrote:
>>>>>>>> I think a compat package would make the coupling between server
>>>>>>>> and client looser, (i.e. one could run old clients on the same
>>>>>>>> machine as a new server).
>>>>>>>>
>>>>>>>> Due to limited time and dependency on qemu on some of my
>>>>>>>> testing machines, I still have not been able to test
>>>>>>>> 3.6.0beta3. A -compat package would have helped me a lot (but
>>>>>>>> maybe given you more bugs to fix :-)).
>>>>>>> Hi,
>>>>>>>
>>>>>>> Here's an experimental respin of 3.6.0beta3 with a -compat RPM.
>>>>>>>
>>>>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=7981431
>>>>>>>
>>>>>>> Please let us know how it works. The 3.6 release is coming very
>>>>>>> soon and if this works we'd like to include it in our Fedora and
>>>>>>> EPEL packages.
>>>>>> Nope, does not work, since the running usr/lib/rpm/find-provides
>>>>>> (or /usr/lib/rpm/redhat/find-provides) on the symlink does not
>>>>>> yield the proper provides [which for my system should be
>>>>>> "libgfapi.so.0()(64bit)"]. So no cigar :-(
>>>>> Hi,
>>>>>
>>>>> 1) I erred on the symlink in the -compat RPM. It should have been
>>>>> /usr/lib64/libgfapi.so.0 -> libgfapi.so.7(.0.0).
>>>> Noticed that, not the main problem though :-)
>>>>
>>>>> 2) find-provides is just a wrapper that greps the SO_NAME from the
>>>>> shared lib. And if you pass symlinks such as
>>>>> /usr/lib64/libgfapi.so.7 or /usr/lib64/libgfapi.so.0 to it, they both
>>>>> return the same result, i.e. the null string. The DSO run-time does
>>>>> not check that the SO_NAME matches.
>>>> No, but yum checks for "libgfapi.so.0()(64bit) / libgfapi.so.0", so
>>>> i think something like this is needed for yum to cope with upgrades.
>>>>
>>>> %ifarch x86_64
>>>> Provides:         libgfapi.so.0()(64bit)
>>>> %else
>>>> Provides:         libgfapi.so.0
>>>> %endif
>>>
>>> That's already in the glusterfs-api-compat RPM that I sent you. The 64-bit part anyway. Yes, a complete fix would include the 32-bit too.
>> A looked/tried at the wrong RPM
>>
>>>>
>>>>> I have a revised set of rpms with a correct symlink available
>>>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=7984220. The main
>>>>> test (that I'm interested in) is whether qemu built against 3.5.x
>>>>> works with it or not.
>>>> First thing is to get a yum upgrade to succeed.
>>> What was the error?
>> Me :-( (putting files in the wrong location)
>>
>> Unfortunately hard to test, my libvirtd (1.1.3.6) seems to lack gluster support
>> (even though qemu is linked against libvirtd), any recommended version of libvirtd to
>> compile?
> With (srpms from fc21)
>
> libvirt-client-1.2.9-3.fc20.x86_64
> libvirt-daemon-1.2.9-3.fc20.x86_64
> libvirt-daemon-driver-interface-1.2.9-3.fc20.x86_64
> libvirt-daemon-driver-network-1.2.9-3.fc20.x86_64
> libvirt-daemon-driver-nodedev-1.2.9-3.fc20.x86_64
> libvirt-daemon-driver-nwfilter-1.2.9-3.fc20.x86_64
> libvirt-daemon-driver-qemu-1.2.9-3.fc20.x86_64
> libvirt-daemon-driver-secret-1.2.9-3.fc20.x86_64
> libvirt-daemon-driver-storage-1.2.9-3.fc20.x86_64
> libvirt-daemon-kvm-1.2.9-3.fc20.x86_64
> libvirt-daemon-qemu-1.2.9-3.fc20.x86_64
> libvirt-devel-1.2.9-3.fc20.x86_64
> libvirt-docs-1.2.9-3.fc20.x86_64
> libvirt-gconfig-0.1.7-2.fc20.x86_64
> libvirt-glib-0.1.7-2.fc20.x86_64
> libvirt-gobject-0.1.7-2.fc20.x86_64
> libvirt-python-1.2.7-2.fc20.x86_64
>
> I can create a gluster pool, but when trying to create
> an image I get the error "Libvirt version does not support storage cloning".
> Will continue tomorrow.

As you noticed, this looks to be a libvirt version specific issue.
>
> Qemu's that does not touch gluster works OK, so the installation is OK right now :-)

I read it as, 'compat package works' !
>
>
>>>>>> Have you checked my more heavyhanded http://review.gluster.org/9014
>>>>>> ?
>>>>> I have. A) it's, well, heavy handed ;-) mainly due to,
>>>>> B) there's lot of duplicated code for no real purpose, and
>>>> Agreed, quick fix to avoid soname hell (and me being unsure of
>>>> what problems __THROW could give rise to).
>>> In C, that's a no-op. In C++, it tells the compiler that the function does not throw exceptions and can optimize accordingly.
>> OK, no problems there then.
>>
>>>>> C) for whatever reason it's not making it through our smoke and
>>>>> regression tests (although I can't imagine how a new and otherwise
>>>>> unused library would break those.)
>>>> Me neither, but I'm good at getting smoke :-)
>>>>
>>>>> If it comes to it, I personally would rather take a different route
>>>>> and use versioned symbols in the library and not bump the SO_NAME.
>>>>> Because the old APIs are unchanged and all we've done is add new
>>>>> APIs.
>>>> I guess we have passed that point since 3.6.0 is out in the wild (RHEL),
>>>> and no way to bump down the version number.
>>> That's RHS-Gluster, not community gluster. There's been some discussion of not packaging 3.6.0 and releasing and packaging 3.6.1 in short order. We might have a small window of opportunity. (Because there's never time to do it right the first time, but there's always time to do it over. ;-)
>>>
>>>>
>>>>> But we're running out of time for the 3.6 release (which is already
>>>>> months overdue.)
>> So is my testing, hope I'm not the bottleneck here :-)
>>
>>>>> I don't know if anyone here looked at doing versioned symbols before
>>>>> we made the decision to bump the SO_NAME. I've looked at Ulrich
>>>>> Dreppers
>>>>> https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf
>>>>> write-up and it's not very hard.
>>>> Too late now, though?
>>> Perhaps not.
>> +2
>>
>>
>>
>> /Anders
>>
>

-- 
Cheers,
Humble

Senior Software  Engineer
RH India