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

Wed Feb 12 16:15:28 UTC 2014

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.

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