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

[Thiago da Silva]

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 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
>