On 08/17/2013 12:45 AM, Justin Clift wrote:
On 16/08/2013, at 8:11 PM, Harshavardhana wrote:
On Fri, Aug 16, 2013 at 11:48 AM, Justin Clift jcl...@redhat.com wrote:
snip
As a separate project, any thoughts on us replacing the current CLI with
a new one, based upon having a more complete
On 15/08/2013, at 7:33 PM, Kaleb KEITHLEY wrote:
On 08/15/2013 07:40 AM, Justin Clift wrote:
On 15/08/2013, at 5:51 AM, Anand Babu Periasamy wrote:
snip
* Modular GlusterFS CLI API. Today it is hard-coded.
Not so sure about this one. Allowing for dynamic additions to
the CLI (eg using the
On Fri, Aug 16, 2013 at 11:48 AM, Justin Clift jcl...@redhat.com wrote:
On 15/08/2013, at 7:33 PM, Kaleb KEITHLEY wrote:
On 08/15/2013 07:40 AM, Justin Clift wrote:
On 15/08/2013, at 5:51 AM, Anand Babu Periasamy wrote:
snip
* Modular GlusterFS CLI API. Today it is hard-coded.
Not so
On 16/08/2013, at 8:11 PM, Harshavardhana wrote:
On Fri, Aug 16, 2013 at 11:48 AM, Justin Clift jcl...@redhat.com wrote:
snip
As a separate project, any thoughts on us replacing the current CLI with
a new one, based upon having a more complete RESTful API + a new CLI that
does nothing but be
On 08/12/2013 03:52 PM, Justin Clift wrote:
On 12/08/2013, at 8:50 PM, Jay Vyas wrote:
okay makes sense. so .. um How about json ? :)
Yeah, might be a bunch more readable. Also easier to
work with from things like Node.js.
Just personally not sure how to structure it well
with JSON.
We have had this discussion during our management framework and GUI design
sessions. My suggestion is to separate the management framework in to a
glusterd like daemon running on each node. They expose RESTful APIs. Client
can be implemented in python like higher level scripting languages. RESTful
On 16/08/2013, at 8:51 PM, Anand Babu Periasamy wrote:
We have had this discussion during our management framework and GUI design
sessions. My suggestion is to separate the management framework in to a
glusterd like daemon running on each node. They expose RESTful APIs. Client
can be
On 15/08/2013, at 5:51 AM, Anand Babu Periasamy wrote:
Here are some more points to consider:
* gluster-devel package should include all the necessary header and
library files to compile a standalone glusterfs translator.
That definitely makes sense. :)
*
On 08/15/2013 07:40 AM, Justin Clift wrote:
On 15/08/2013, at 5:51 AM, Anand Babu Periasamy wrote:
Here are some more points to consider:
* gluster-devel package should include all the necessary header and
library files to compile a standalone glusterfs translator.
That definitely makes
On Thu, Aug 15, 2013 at 11:33 AM, Kaleb KEITHLEY kkeit...@redhat.com wrote:
On 08/15/2013 07:40 AM, Justin Clift wrote:
On 15/08/2013, at 5:51 AM, Anand Babu Periasamy wrote:
Here are some more points to consider:
* gluster-devel package should include all the necessary header and
Adding development headers to the deb has been on my todo list for a week
already. I'll get on that Real Soon Now (in the next few days, I hope).
I'll probably ping on IRC when I'm working on it.
Thanks!
-louis
On Thu, Aug 15, 2013 at 2:33 PM, Kaleb KEITHLEY kkeit...@redhat.com wrote:
On
On 12/08/2013, at 6:52 PM, Justin Clift wrote:
snip
For 3.5, I'd like to propose we add a way for people to easily
add custom translators they've written. (using C, or Glupy,
or whatever)
Added this initial proposal to the 3.5 planning page:
Here are some more points to consider:
* gluster-devel package should include all the necessary header and
library files to compile a standalone glusterfs translator.
* /usr/share/doc/gluster-devel/examples/translators/hello-world
should contain skeleton translator code (well commented),
Hi all,
For 3.5, I'd like to propose we add a way for people to easily
add custom translators they've written. (using C, or Glupy,
or whatever)
I'm not actually sure (yet) how we'd go about doing it, so
would like to discuss it first before writing things up. :)
As a first thought, maybe we
i like the install file idea. packaging always seems easier and
memorizing CLI magic seems like another feature which would lend itself
more to forcing devs to read documentation to get it working correctly.
The deployment via packaging is always easier to modify and learn on the
fly
On 12/08/2013, at 7:44 PM, Jay Vyas wrote:
i like the install file idea. packaging always seems easier and memorizing
CLI magic seems like another feature which would lend itself more to forcing
devs to read documentation to get it working correctly. The deployment via
packaging is
okay makes sense. so .. um How about json ? :)
___
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel
On 12/08/2013, at 8:50 PM, Jay Vyas wrote:
okay makes sense. so .. um How about json ? :)
Yeah, might be a bunch more readable. Also easier to
work with from things like Node.js.
Just personally not sure how to structure it well
with JSON.
Suggestions? :)
+ Justin
--
Open Source and
On 08/12/2013 12:52 PM, Joe Julian wrote:
On 08/12/2013 12:17 PM, Justin Clift wrote:
On 12/08/2013, at 7:44 PM, Jay Vyas wrote:
i like the install file idea. packaging always seems easier and
memorizing CLI magic seems like another feature which would lend
itself more to forcing devs to
On 12/08/2013, at 8:55 PM, Joe Julian wrote:
snip
Or as json:
{
translator: {
name: features/marker,
type: server,
graph: { before: debug/io-stats },
subvolume: { count: 1 },
cli: {
target: volume,
options: {
option: [
{
name:
On 08/12/2013 01:52 PM, Justin Clift wrote:
For 3.5, I'd like to propose we add a way for people to easily add custom
translators they've written. (using C, or Glupy, or whatever)
I'm not actually sure (yet) how we'd go about doing it, so would like to
discuss it first before writing things up.
21 matches
Mail list logo
