[Gluster-devel] Integrating liburcu source into the glusterfs source tree

[Kaushal M]

I'm currently testing my changes with liburcu-0.7.* . It is missing just
one API which I'm using from 0.8. I've written a local implementation of
just that one function, and am currently in process of testing this. If
this test is successful, then our problems will be minimized.

This only leaves out Debian Wheezy and Ubuntu Precise with liburcu-0.6.* .
I tried testing this out, but as liburcu-0.6 doesn't apparently provide
pkg-config configurations, I stopped as soon as I started.

~kaushal


On Mon, Feb 2, 2015 at 2:37 PM, Niels de Vos <ndevos at redhat.com> wrote:

> On Mon, Feb 02, 2015 at 09:10:36AM +0530, Kaushal M wrote:
> > Thanks for this information Kaleb.
> >
> > I'll check the changes I've done till now with the older versions of the
> > libraries. I think I'm going to need at least the 0.8.* release of
> liburcu,
> > as some new apis were introduced in it, which I'm using. I'll post the
> > outcome of my tests back here.
> >
> > For a start, I collected the various versions of liburcu (userspace-rcu
> in
> > some) available in the different distros. This list is based on the
> distros
> > for which we provide community built packages and test on.
> >
> > - Fedora 21 - 0.8.1 (0.8.5 in testing but stuck due to some breakages)
> > - Fedora 20 - 0.7.7 (0.8.5 in testing but stuck due to some breakages)
> > - EL7 - 0.7.9
> > - EL6 - 0.7.7
> > - Debian Wheezy - 0.6.7
> > - Debian Jessie - 0.8.5 (in testing)
> > - Ubuntu Precise - 0.6.7
> > - Ubuntu Trusty - 0.7.12
> > - Ubuntu Utopic - 0.8.4
> > - Netbsd - 0.8.6
> > - Freebsd - 0.7.7
> >
> > The list doesn't look too good.
>
> I do not like including libraries in the glusterfs sources. Currently
> there are several bits under contrib/ that do not see any maintenance.
> Who will be maintaining (fixing potential bugs, backporting newer
> versions, ...) for linurcu? Note that we support *many* different
> distributions, architectures and master+3 releases.
>
> It would be *so* much more efficient to use the distributions version of
> liburcu. Maybe it is possible to write some wrapper functions for the
> older versions of the library, and place those wrappers in contrib/
> instead?
>
> Alternatively, we could maintain packages for liburcu in our
> repositories on download.gluster.org for distributions that do not have
> a recent enough version. You will need to find a relyable packager that
> agrees to take on this task.
>
> Niels
>
> >
> > ~kaushal
> >
> >
> > On Fri, Jan 30, 2015 at 6:30 PM, Kaleb KEITHLEY <kkeithle at redhat.com>
> wrote:
> >
> > > Hi,
> > >
> > > Just FYI, what you propose is called bundling in Fedora packaging
> > > parlance, and Fedora's packaging guidelines forbid bundling. It is
> possible
> > > to get an exception granted, but it's not safe to presume that an
> exception
> > > will be granted.
> > >
> > > (For downstream this is a non-issue, but here on gluster-devel we're
> not
> > > concerned with downstream.)
> > >
> > > You either need to convince the maintainers of liburcu to update to the
> > > newer versions everywhere, or you need to implement using the oldest
> > > version on the platforms you intend to support. And if this is too
> onerous,
> > > e.g. to use what's in (RH)EL5, then it's another argument in favor of
> > > dropping support for (RH)EL5. (The other argument is that python on
> RHEL5
> > > is too old for geo-rep.)
> > >
> > > In short, those of use who package gluster in Fedora would be, however
> > > reluctantly, required to vote against doing this. I recommend
> contacting
> > > the liburcu maintainers in Fedora/EPEL and see if you can't convince
> them
> > > to update to the newest version.
> > >
> > > Regards,
> > >
> > > --
> > >
> > > Kaleb
> > >
> > > /30/2015 12:09 PM, Deepak Shetty wrote:
> > >
> > >>
> > >>
> > >> On Thu, Jan 29, 2015 at 5:05 PM, Kaushal M <kshlmster at gmail.com
> > >> <mailto:kshlmster at gmail.com>> wrote:
> > >>
> > >>     Hi all,
> > >>     I had started a thread previously on the efforts we are
> undertaking
> > >>     to improve thread synchronization in GlusterD [1]. I had mentioned
> > >>     that we will be using RCU for synchronization and the userspace
> RCU
> > >>     library (liburcu) [2] for implementation.
> > >>
> > >>     I am now in a almost in a position to submit changes to Gerrit for
> > >>     review. But, I have an obstacle of making liburcu available on the
> > >>     jenkins slaves.
> > >>
> > >>     I have begun development using the 0.8.6 version of liburcu, which
> > >>     is the latest stable release. EPEL has liburcu packages for
> CentOS 6
> > >>     and 7, but they are the of the older 0.7.* versions. Fedora has
> > >>     packages more recent packages, but they are still older, 0.8.1.
> [3].
> > >>
> > >>     Considering the above situation with binary packages, I'm
> > >>     considering adding liburcu into the GlusterFS tree as a part of
> > >>     /contrib. This will be similar in vein to the argp-standalone
> library.
> > >>
> > >>     liburcu is licensed under LGPL-v2.1, so I don't think there is
> going
> > >>     to be any problem including it. But IANAL, so I would like to know
> > >>     of if this would if this is okay from a legal perspective.
> > >>
> > >>     I'll add the liburcu source to our tree and push the change for
> > >>     review. I'm not really familiar with autotools, so I'll need some
> > >>     help integrating it into our build system. I'll update the list
> when
> > >>     I have pushed the change for review.
> > >>
> > >>
> > >> How do you intend to add, as a git submodule or ?
> > >> I had worked on GNU autotools in the past, but frankly don't remember
> > >> much of it. If any help is needed I can try, or can get someone to
> help
> > >> from my ex-company :)
> > >>
> > >> thanx,
> > >> deepak
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> Gluster-devel mailing list
> > >> Gluster-devel at gluster.org
> > >> http://www.gluster.org/mailman/listinfo/gluster-devel
> > >>
> > >>
> > >
>
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150202/4b826c60/attachment.html>