[Gluster-devel] Glupy bugs: found the solution?

Wed Feb 12 16:33:57 UTC 2014

On Wed, 2014-02-12 at 17:15 +0100, Niels de Vos wrote:
> On Tue, Feb 11, 2014 at 02:47:57PM -0500, Thiago da Silva wrote:
> > Hi Justin, 
> > 
> > I have started the work, but it is not yet complete. We currently have
> > the same functions that was part of the example code. I think this is
> > good enough so that the existing Python libgfapi can be removed from
> > Gluster 3.5 dev tree. This way I can also start working to create a
> > separate rpm, which gluster-swift would depend on once we make the move
> > away from fuse.
> 
> I suggest to not do this for 3.5, but rather for 3.6. That gives you 
> some time to prepare the package and provide it in Fedora and all.  
> Currently glusterfs-api provides python-glusterfs (I think) where 
> gluster-swift can depend on. Your package would have that Provides: as 
> well. This should allow a relatively easy transition.
Very good point, sounds like 3.5 is just around the corner and we would
not have enough time to prepare the new package and get it included in
Fedora.

Thanks!

Thiago
> 
> Cheers,
> Niels
> 
> > 
> > I have separated the tests to their own files and we have both unit and
> > functional tests running automatically on Jenkins
> > (http://build.gluster.org).
> > 
> > I'm currently working with Ben England to run some tests with his
> > smallfile.py project (https://github.com/bengland2/smallfile)
> > 
> > I don't think it is ready yet for real world usage, but we are moving
> > towards that...
> > 
> > Thiago
> > 
> > 
> > 
> > 
> > On Tue, 2014-02-11 at 19:13 +0000, Justin Clift wrote:
> > > Hi Thiago,
> > > 
> > > How's this stuff going?  Is it ready enough for real world usage?
> > > 
> > > eg should we think about ripping the existing Python libgfapi code
> > > out of main Gluster 3.5 dev tree, and using this instead? :)
> > > 
> > > Regards and best wishes,
> > > 
> > > Justin Clift
> > > 
> > > 
> > > On 29/10/2013, at 1:34 PM, Luis Pabon wrote:
> > > > Hi guys,
> > > >     On the python bindings side, we have hired a new developer to spend his time divided between gluster-swift and the python bindings for gfapi (and probably Java binding on some future date).  His name is Thiago da Silva and he started a few weeks ago.
> > > >     The gluster-swift project will require, in the near future, to move from using FUSE to libgfapi, and so we really need to the python bindings to become a real project:  python exceptions, unit tests, functional tests, documentation, releases, etc.
> > > >     We are also planning on moving the bindings away from the glusterfs repo to a new repo.  We have been really busy working on SWAuth for Gluster-swift, but we plan on using the same development workflow as gluster-swift in python-libgfapi repo.
> > > > 
> > > >     Here is the repo information:
> > > > Public Repo: https://github.com/gluster/libgfapi-python  (for some reason it is not syncing with Gerrit.  I'll ping Avati)
> > > > Gerrit:  http://review.gluster.org/libgfapi-python 
> > > > 
> > > > - Luis
> > > > 
> > > > On 10/28/2013 03:28 PM, Justin Clift wrote:
> > > >> On 27/10/2013, at 8:37 AM, Niels de Vos wrote:
> > > >> <snip>
> > > >> 
> > > >>>> Yeah, that's why I was thinking it was libgfapi stuff getting pulled in
> > > >>>> not Swift.  The import line in your pdf needs updating btw, as the
> > > >>>> import line for current git head needs to be:
> > > >>>> 
> > > >>>>  from gluster import gfapi
> > > >>>> 
> > > >>> Ah, right. I'm not sure I'll update that because at the time of the 
> > > >>> presentation one needed to use the git repository. During the Gluster 
> > > >>> Community Day in Stockholm someone (sorry, can't remember the name) 
> > > >>> asked if gfapi.py could not be included in the packages. Good question, 
> > > >>> and it showed I wasn't the only one who would benefit from that ;-)
> > > >>> 
> > > >> Kind of thinking this through further, gfapi.py is kind of serving two
> > > >> roles at the moment (import + demo).
> > > >> 
> > > >> Should we improve that by moving the import code into a "more proper"
> > > >> gfapi.py under api/src/, keeping the Python demo code in the examples
> > > >> ("gfapi-demo.py" or similar?)
> > > >> 
> > > >> 
> > > >> 
> > > >>>> <snip>
> > > >>>> 
> > > >>>>> the Python package 'gluster' will be the base for other modules. Hence 
> > > >>>>> we have created put the api bindings in gluster/gfapi.py. I think it 
> > > >>>>> would make sense to rename the Glupy module gluster.glupy. If it can be 
> > > >>>>> placed in /usr/lib/python2.6/site-packages/gluster/glupy.py things would 
> > > >>>>> be even nicer :)
> > > >>>>> 
> > > >>>> That would make the import line:
> > > >>>> 
> > > >>>>  from gluster import glupy
> > > >>>> 
> > > >>>> Wouldn't it?  No objections to that, it's fairly simple and pretty logical. :)
> > > >>>> 
> > > >>> Yes, that's my suggestion. I am not maintaining or developing Glupy, so 
> > > >>> it is not my call and I have no insight if this would make things more 
> > > >>> complex somewhere else. I'm still planning to have a look at Glupy, but 
> > > >>> I have not found the time to do so yet...
> > > >>> 
> > > >> 
> > > >> Sure, np.  Jeff was wanting to hand the code off to someone else, either
> > > >> myself or Ram as we both put time into it.  Not sure if Ram "officially"
> > > >> picked it up or not. ;)
> > > >> 
> > > >> I'd be happy to, but there is some technical challenge there... I don't
> > > >> understand Python Ctypes at all, and it's not absorbing into me head
> > > >> (have tried). :(
> > > >> 
> > > >> + Justin
> > > >> 
> > > >> --
> > > >> Open Source and Standards @ Red Hat
> > > >> 
> > > >> twitter.com/realjustinclift
> > > >> 
> > > >> 
> > > >> _______________________________________________
> > > >> Gluster-devel mailing list
> > > >> 
> > > >> Gluster-devel at nongnu.org
> > > >> https://lists.nongnu.org/mailman/listinfo/gluster-devel
> > > > 
> > > 
> > > --
> > > Open Source and Standards @ Red Hat
> > > 
> > > twitter.com/realjustinclift
> > > 
> > 
> > 