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
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-users
