Re: [Gluster-devel] Glupy bugs: found the solution?
On Sun, 20 Oct 2013 23:08:41 -0400 (EDT) Ramana Raja wrote: > Hi Justin, > > Initially, I ran into the same problems as you did. The problem was that > Glupy's translators (negative, debug) were not importing Glupy's gluster > module, which is the actual python glue, but instead importing > Gluster-swift's gluster module :(. So all I had to do was to rename Glupy's > gluster module as glupy_gluster and the translators began to work. Interestingly, I just got time to try this, and it did work: $ sudo gluster volume stop playground $ sudo systemctl stop glusterd $ sudo mv /usr/lib64/glusterfs/3git/xlator/features/glupy/gluster.py /usr/lib64/glusterfs/3git/xlator/features/glupy/gluster_glupy.py $ sudo rm /usr/lib64/glusterfs/3git/xlator/features/glupy/gluster.py? $ sudo systemctl start glusterd $ sudo gluster volume start playground Then changed helloworld.py from: from gluster import * to: from gluster_glupy import * and Voila, the correct output appears when starting a volume using the helloworld translator: Python xlator: Hello! > Can you please check if your Glupy translators are importing the Glupy's > gluster module, and not something else? > I did this as follows: > - Inserted pdb.set_trace() as the first line of negative.py > - While Pdb-ing, ran "print sys.modules['gluster']" after "from gluster > import *" was executed I haven't used Pdb before, instead I'm using PyCharm (an IDE). I need to figure out how to get the debugger in that working with Glupy translators so I can find out what's being called from where. Kind of suspecting it might be the libgfapi stuff (not Swift) getting picked up on my system instead of Glupy. But really, I have no idea for sure and could easily be wrong. > I'll send a patch to Gluster upstream renaming Glupy's gluster module as > gluster_glupy by citing module-name conflict issues. I still feel this isn't the right approach. Swift is just a component of an external project, whereas Glupy is a component of our own project. So, if anything needs renaming it should be the Swift component not the Glupy one. Does that make sense? :) Regards and best wishes, Justin Clift > Hope your Glupy works. > > > Thanks, > > Ram -- Justin Clift ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Glupy bugs: found the solution?
On Sat, Oct 26, 2013 at 03:33:10PM +0100, Justin Clift wrote: > On Sun, 20 Oct 2013 23:08:41 -0400 (EDT) > Ramana Raja wrote: > > > Hi Justin, > > > > Initially, I ran into the same problems as you did. The problem was that > > Glupy's translators (negative, debug) were not importing Glupy's gluster > > module, which is the actual python glue, but instead importing > > Gluster-swift's gluster module :(. So all I had to do was to rename Glupy's > > gluster module as glupy_gluster and the translators began to work. > > Interestingly, I just got time to try this, and it did work: > > $ sudo gluster volume stop playground > $ sudo systemctl stop glusterd > $ sudo mv /usr/lib64/glusterfs/3git/xlator/features/glupy/gluster.py > /usr/lib64/glusterfs/3git/xlator/features/glupy/gluster_glupy.py > $ sudo rm /usr/lib64/glusterfs/3git/xlator/features/glupy/gluster.py? > $ sudo systemctl start glusterd > $ sudo gluster volume start playground > > Then changed helloworld.py from: > > from gluster import * > > to: > > from gluster_glupy import * > > and Voila, the correct output appears when starting a volume > using the helloworld translator: > > Python xlator: Hello! > > > > Can you please check if your Glupy translators are importing the Glupy's > > gluster module, and not something else? > > I did this as follows: > > - Inserted pdb.set_trace() as the first line of negative.py > > - While Pdb-ing, ran "print sys.modules['gluster']" after "from gluster > > import *" was executed > > I haven't used Pdb before, instead I'm using PyCharm (an IDE). I need > to figure out how to get the debugger in that working with Glupy > translators so I can find out what's being called from where. > > Kind of suspecting it might be the libgfapi stuff (not Swift) > getting picked up on my system instead of Glupy. But really, That is correct. Recent glusterfs-api RPMs provide /usr/lib/python2.6/site-packages/gluster/gfapi.py so that a future swift implementation can use that. It is also trivial to write your own Python script that imports gluster.gfapi and accesses volumes through libgfapi. See slide 10 from http://people.redhat.com/ndevos/talks/Gluster-Stockholm-20130902.pdf for a minimal example. > I have no idea for sure and could easily be wrong. > > > > I'll send a patch to Gluster upstream renaming Glupy's gluster > > module as gluster_glupy by citing module-name conflict issues. > > I still feel this isn't the right approach. Swift is just a component > of an external project, whereas Glupy is a component of our own project. After several discussions with different developers, it was decided that 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 :) HTH, Niels > > So, if anything needs renaming it should be the Swift component not > the Glupy one. > > Does that make sense? :) > > Regards and best wishes, > > Justin Clift > > > > Hope your Glupy works. > > > > > > Thanks, > > > > Ram > > > -- > Justin Clift > > ___ > Gluster-devel mailing list > Gluster-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Glupy bugs: found the solution?
On Sat, 26 Oct 2013 17:47:17 +0200 Niels de Vos wrote: > > I haven't used Pdb before, instead I'm using PyCharm (an IDE). I need > > to figure out how to get the debugger in that working with Glupy > > translators so I can find out what's being called from where. Been trying this out for a few hours while on the train back from Edinburgh (Linuxcon Europe), without success. Kind of suspecting I'll need to learn pdb soon. :( It's kind of weird, as I'm pretty sure I *used* to have this working with an older version of PyCharm (2.7.x). The new 3.0 version of PyCharm is just giving me SEGFAULT and SIGABRT when I try to get a Gluster translator working with it (frustrating). /me will keep trying different things for a bit > > Kind of suspecting it might be the libgfapi stuff (not Swift) > > getting picked up on my system instead of Glupy. But really, > > That is correct. Recent glusterfs-api RPMs provide > /usr/lib/python2.6/site-packages/gluster/gfapi.py so that a future swift > implementation can use that. It is also trivial to write your own Python > script that imports gluster.gfapi and accesses volumes through libgfapi. > See slide 10 from > http://people.redhat.com/ndevos/talks/Gluster-Stockholm-20130902.pdf for > a minimal example. 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 > 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. :) + Justin -- Justin Clift ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Glupy bugs: found the solution?
On Sat, Oct 26, 2013 at 06:57:07PM +0100, Justin Clift wrote: ... ... > > > Kind of suspecting it might be the libgfapi stuff (not Swift) > > > getting picked up on my system instead of Glupy. But really, > > > > That is correct. Recent glusterfs-api RPMs provide > > /usr/lib/python2.6/site-packages/gluster/gfapi.py so that a future swift > > implementation can use that. It is also trivial to write your own Python > > script that imports gluster.gfapi and accesses volumes through libgfapi. > > See slide 10 from > > http://people.redhat.com/ndevos/talks/Gluster-Stockholm-20130902.pdf for > > a minimal example. > > 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 ;-) > > > 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... Niels ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Glupy bugs: found the solution?
On 27/10/2013, at 8:37 AM, Niels de Vos wrote:
>> 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?)
>>
>>> 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@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Glupy bugs: found the solution?
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:
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?)
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@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Glupy bugs: found the solution?
On Tue, 29 Oct 2013 09:34:33 -0400 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. Excellent. Sounds good to me. :) > We are also planning on moving the bindings away from the glusterfs > repo to a new repo. That's interesting. What's the benefit from having it in it's own repo? Is there any chance that could let us have Libgfapi (client side) be cross platform? eg Windows, OSX, (Android?), *BSD clients be able to connect to Linux Gluster servers? > 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 Neither of those URL's work atm. Guess they will in future. :) + Justin -- Justin Clift ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Glupy bugs: found the solution?
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:
>>
>>
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?)
>>
>>
>>
> 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@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
--
Open Source and Standards @ Red Hat
twitter.com/realjustinclift
___
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Glupy bugs: found the solution?
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 +, 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:
> >>
> >>
> 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?)
> >>
> >>
> >>
>
>
> > 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@nongnu.org
> >> https://lists.nongnu.org/mailman/listinfo/gluster-devel
> >
>
> --
> Open Source and Standards @ Red Hat
>
> twitter.com/realjustinclift
>
___
Gluster-devel mailing list
G
Re: [Gluster-devel] Glupy bugs: found the solution?
On 11/02/2014, at 7:47 PM, 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 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... No worries. :) As a thought, some of the code here maybe a useful addition: http://review.gluster.org/#/c/6158/3/api/examples/gfapi.py http://review.gluster.org/#/c/6158/ I'd started adding docstrings, functions, and fixing one or two bugs in Gluster code base a while ago, but then went on holiday. It might apply cleanly to your gfapi.py, though I haven't written any unit tests for it (yet). Guess I should look at making a pull request with the code... :) + Justin > Thiago -- Open Source and Standards @ Red Hat twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Glupy bugs: found the solution?
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 +, 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:
> > >>
> > >>
> > 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?)
> > >>
> > >>
> > >>
> >
> >
> > > 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. ;)
Re: [Gluster-devel] Glupy bugs: found the solution?
Thanks for the link, I will make sure to incorporate those changes to the new code. It will also server as a good starting point for a new functions. On Wed, 2014-02-12 at 06:53 +, Justin Clift wrote: > On 11/02/2014, at 7:47 PM, 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 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... > > No worries. :) > > As a thought, some of the code here maybe a useful addition: > > http://review.gluster.org/#/c/6158/3/api/examples/gfapi.py > http://review.gluster.org/#/c/6158/ > > I'd started adding docstrings, functions, and fixing one or two bugs > in Gluster code base a while ago, but then went on holiday. > > It might apply cleanly to your gfapi.py, though I haven't written > any unit tests for it (yet). > > Guess I should look at making a pull request with the code... :) > > + Justin > > > > Thiago > > -- > Open Source and Standards @ Red Hat > > twitter.com/realjustinclift > ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Glupy bugs: found the solution?
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 +, 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:
> > > >>
> > > >>
> > > 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?)
> > > >>
> > > >>
> > > >>
> > >
> > >
> > > > 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
