Re: [Ganglia-developers] add extras parsing to json graph-definitions
On Thu, Jul 19, 2012 at 8:54 AM, Jochen Hein joc...@jochen.org wrote: Vladimir Vuksan vli...@veus.hr writes: I would define a scaling factor or some other variable. I do want to steer away from having tool specific options unless absolutely necessary. I agree that would be a useful goal, I just have no idea what I options I may need for my special problem [see my mail to ganglia-general]. I've had a look at the other PHP-reports. A couple of them pass the option '--rigid' to rddtool. Other used options are --logarithmic and --lower-limit. I've no idea how that could be mapped into json and keep the syntax and the parsing simple. Speaking as the one who wrote[1] a good chunk of the original modular report code, the idea for for the 'extras' variable is to allow the report writer to make whatever changes to make the graph look the way they want. This includes overriding the default settings. The various options cited, such as --rigid and --logarithmic, are perfect examples. Quoting from graph.php: /* The $extras variable is used for other arguemnts that may not * fit nicely for other reasons. Complicated requests for --color, or adding --ridgid, for example. * It is simply a way for the graph writer to add an arbitrary options when calling rrdtool, and to * forcibly override other settings, since rrdtool will use the last version of an option passed. */ Note that this *predates* JSON support, and when I wrote the code, there had been zero mention of any other backends other than rrdtool. It's worth nothing that a lot, perhaps even most, of the graphing code is rrdtool specific. However, I don't see any particular reason why the JSON code in graph.php should not make use of the 'extras' graph variable. Short of re-writing the graphing API (so to speak), this seems a reasonable solution in the short term. I agree with Vladimir that something generic is preferable, but I expect that something sufficiently generic won't be much use. We'll have a data structure that includes a handful of values for title, x/y label, and a massive string or array of all_the_other_options_for_this_graph_type. [1] Or screwed up horribly, take your pick. -- Jesse Becker -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] add extras parsing to json graph-definitions
On Thu, Jul 19, 2012 at 8:54 AM, Jochen Hein joc...@jochen.org wrote:
Vladimir Vuksan vli...@veus.hr writes:
I would define a scaling factor or some other variable. I do want to
steer away from having tool specific options unless absolutely
necessary.
I agree that would be a useful goal, I just have no idea what I options
I may need for my special problem [see my mail to ganglia-general].
I've had a look at the other PHP-reports. A couple of them pass the
option '--rigid' to rddtool. Other used options are --logarithmic and
--lower-limit. I've no idea how that could be mapped into json and keep
the syntax and the parsing simple.
I'd suggest something like:
options: {
logarithmic: true,
rigid: false,
lower-limit: 0
}
with sensible defaults. If it's ignored by another graphing toolkit,
that's fine.
Jeff
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
[Ganglia-developers] web and debian/* files
The web download includes a debian/ directory with files for building a Debian package Debian also keeps a separate set of files for the same purpose in the Debian git VCS: git.debian.org/git/collab-maint/ganglia-web.git When importing release tarballs into the Debian VCS, it is necessary to filter out the upstream version of the debian/* files, they don't get used at all: git-import-orig -u 3.5.2 --filter='debian/*' ~/Downloads/ganglia-web_3.5.2.orig.tar.gz To simplify things and avoid duplication, debian/* could be omitted from future gweb releases (and even removed from the git repo) Would anyone object to that? I believe that the main advantage of tracking these files in Debian's git is that any Debian developer can update them and update an emergency bug fix release at any time. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] web and debian/* files
Hi Daniel: One reason why we would want to keep the debian/ directory in our repo is if for whatever reason the upstream Debian package doesn't get updated, a user could still download our official tarball and build Debian packages directly. Cheers, Bernard On Thu, Jul 19, 2012 at 7:41 AM, Daniel Pocock dan...@pocock.com.au wrote: The web download includes a debian/ directory with files for building a Debian package Debian also keeps a separate set of files for the same purpose in the Debian git VCS: git.debian.org/git/collab-maint/ganglia-web.git When importing release tarballs into the Debian VCS, it is necessary to filter out the upstream version of the debian/* files, they don't get used at all: git-import-orig -u 3.5.2 --filter='debian/*' ~/Downloads/ganglia-web_3.5.2.orig.tar.gz To simplify things and avoid duplication, debian/* could be omitted from future gweb releases (and even removed from the git repo) Would anyone object to that? I believe that the main advantage of tracking these files in Debian's git is that any Debian developer can update them and update an emergency bug fix release at any time. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] add extras parsing to json graph-definitions
On Jul 19, 2012, at 9:12 AM, Jeff Buchbinder wrote:
On Thu, Jul 19, 2012 at 8:54 AM, Jochen Hein joc...@jochen.org wrote:
Vladimir Vuksan vli...@veus.hr writes:
I would define a scaling factor or some other variable. I do want to
steer away from having tool specific options unless absolutely
necessary.
I agree that would be a useful goal, I just have no idea what I options
I may need for my special problem [see my mail to ganglia-general].
I've had a look at the other PHP-reports. A couple of them pass the
option '--rigid' to rddtool. Other used options are --logarithmic and
--lower-limit. I've no idea how that could be mapped into json and keep
the syntax and the parsing simple.
I'd suggest something like:
options: {
logarithmic: true,
rigid: false,
lower-limit: 0
}
with sensible defaults. If it's ignored by another graphing toolkit,
that's fine.
Silently ignoring unsupported options seems like a bad choice to me, because it
makes graph authoring troubleshooting more difficult. If someone uses an
unsupported option, we should blow up with an informative error message ASAP.
Think about when you've misspelled a configuration option (in any system, not
just gweb), and wasted a lot of time hunting for the cause of the odd results
you see - totally frustrating, and totally preventable.
More generally: The JSON format should be focused on making the simple common
cases easy. The format should be small, simple, easy to use. Allowing lots of
platform-specific options dilutes this value. The PHP route is still available
for the non-trivial cases. If you need RRD-specific features, then I think PHP
is the way to go.
Presenting platform-specific options in a seemingly platform-agnostic way is
worse. If we are going to support JSON options which are really RRD-specific,
we need to make this clear.
One suggestion on how to do this (which I don't like as well, but I'll mention
it anyway): Put RRD-specific options into something like
{rrd-options:--color --rigid --whatever}. This at least gives someone else
a clue that the JSON graph is intended only for use with RRD, rather than
leaving it up to gweb to determine how to interpret logarithmic or rigid
for any graphing platform we want to try supporting.
alex
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] add extras parsing to json graph-definitions
What Alex said.
- Logarithmic is universal so that shouldn't be controversial
Lower-limit and upper-limits are already implemented. Rigid is something
very rrdtool specific so I want to punt on it at this time.
Vladimir
On Thu, 19 Jul 2012, Alex Dean wrote:
On Jul 19, 2012, at 9:12 AM, Jeff Buchbinder wrote:
On Thu, Jul 19, 2012 at 8:54 AM, Jochen Hein joc...@jochen.org wrote:
Vladimir Vuksan vli...@veus.hr writes:
I would define a scaling factor or some other variable. I do want to
steer away from having tool specific options unless absolutely
necessary.
I agree that would be a useful goal, I just have no idea what I options
I may need for my special problem [see my mail to ganglia-general].
I've had a look at the other PHP-reports. A couple of them pass the
option '--rigid' to rddtool. Other used options are --logarithmic and
--lower-limit. I've no idea how that could be mapped into json and keep
the syntax and the parsing simple.
I'd suggest something like:
options: {
logarithmic: true,
rigid: false,
lower-limit: 0
}
with sensible defaults. If it's ignored by another graphing toolkit,
that's fine.
Silently ignoring unsupported options seems like a bad choice to me, because
it makes graph authoring troubleshooting more difficult. If someone uses an
unsupported option, we should blow up with an informative error message ASAP.
Think about when you've misspelled a configuration option (in any system, not
just gweb), and wasted a lot of time hunting for the cause of the odd results
you see - totally frustrating, and totally preventable.
More generally: The JSON format should be focused on making the simple
common cases easy. The format should be small, simple, easy to use.
Allowing lots of platform-specific options dilutes this value. The PHP route
is still available for the non-trivial cases. If you need RRD-specific
features, then I think PHP is the way to go.
Presenting platform-specific options in a seemingly platform-agnostic way is
worse. If we are going to support JSON options which are really RRD-specific,
we need to make this clear.
One suggestion on how to do this (which I don't like as well, but I'll
mention it anyway): Put RRD-specific options into something like
{rrd-options:--color --rigid --whatever}. This at least gives someone
else a clue that the JSON graph is intended only for use with RRD, rather
than leaving it up to gweb to determine how to interpret logarithmic or
rigid for any graphing platform we want to try supporting.
alex
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] web and debian/* files
Exactly. The other day I was actually missing the debian/ directory in ganglia-3.4.0 and as a result couldn't build it due to short timeline. Can we put stuff like that back in. If Debian guys don't like it we can strip it out for them. Vladimir On Thu, 19 Jul 2012, Bernard Li wrote: Hi Daniel: One reason why we would want to keep the debian/ directory in our repo is if for whatever reason the upstream Debian package doesn't get updated, a user could still download our official tarball and build Debian packages directly. Cheers, Bernard On Thu, Jul 19, 2012 at 7:41 AM, Daniel Pocock dan...@pocock.com.au wrote: The web download includes a debian/ directory with files for building a Debian package Debian also keeps a separate set of files for the same purpose in the Debian git VCS: git.debian.org/git/collab-maint/ganglia-web.git When importing release tarballs into the Debian VCS, it is necessary to filter out the upstream version of the debian/* files, they don't get used at all: git-import-orig -u 3.5.2 --filter='debian/*' ~/Downloads/ganglia-web_3.5.2.orig.tar.gz To simplify things and avoid duplication, debian/* could be omitted from future gweb releases (and even removed from the git repo) Would anyone object to that? I believe that the main advantage of tracking these files in Debian's git is that any Debian developer can update them and update an emergency bug fix release at any time. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] web and debian/* files
It becomes problematic when the two /debian subdirs diverge and then you may end up with official debian packages owning a different set of files or having different install locations than ones built directly from upstream. Other packages which depend on or work in concert with packages that provide ganglia-web may break. And the support of two different sources of debian packages claiming to provide ganglia-web may be more than anyone really wants to deal with. -Dave On 07/19/2012 01:55 PM, Vladimir Vuksan wrote: Exactly. The other day I was actually missing the debian/ directory in ganglia-3.4.0 and as a result couldn't build it due to short timeline. Can we put stuff like that back in. If Debian guys don't like it we can strip it out for them. Vladimir On Thu, 19 Jul 2012, Bernard Li wrote: Hi Daniel: One reason why we would want to keep the debian/ directory in our repo is if for whatever reason the upstream Debian package doesn't get updated, a user could still download our official tarball and build Debian packages directly. Cheers, Bernard On Thu, Jul 19, 2012 at 7:41 AM, Daniel Pocockdan...@pocock.com.au wrote: The web download includes a debian/ directory with files for building a Debian package Debian also keeps a separate set of files for the same purpose in the Debian git VCS: git.debian.org/git/collab-maint/ganglia-web.git When importing release tarballs into the Debian VCS, it is necessary to filter out the upstream version of the debian/* files, they don't get used at all: git-import-orig -u 3.5.2 --filter='debian/*' ~/Downloads/ganglia-web_3.5.2.orig.tar.gz To simplify things and avoid duplication, debian/* could be omitted from future gweb releases (and even removed from the git repo) Would anyone object to that? I believe that the main advantage of tracking these files in Debian's git is that any Debian developer can update them and update an emergency bug fix release at any time. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
