19:31:00 <TheSnide> #startmeeting
19:31:00 <MeetBot> Meeting started Tue Apr 22 19:31:00 2014 UTC.  The chair is TheSnide. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:31:00 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:31:10 <TheSnide> hi everyone
19:31:21 <TheSnide> #topic 2.2
19:31:38 <TheSnide> not much happended on that. more on the json side.
19:32:37 <TheSnide> just note that sweet things might come if i find the time :) [enough for teasing]
19:32:44 <TheSnide> #topic json
19:33:01 <TheSnide> that has been my pet feat these days.
19:33:31 <TheSnide> a nice working prototype is out on the json branch, from my personal git.
19:33:53 <TheSnide> I'm going to merge it to devel after the meeting.
19:34:06 <TheSnide> what works so far is :
19:34:31 <TheSnide> - basic access to all tables (grp, node, service, ds)
19:35:13 <TheSnide> - some navigation for tables (currently only by parent key)
19:35:15 <Bushmills> can I have a graph_link plugin config directive?
19:35:41 <TheSnide> explain
19:36:02 <TheSnide> sortof an alias ?
19:36:35 <Bushmills> allowing to configure an url in plugin source, maybe value per environment variable, which is opened when clicking on, for example, the graph title
19:37:09 <Bushmills> idea is mainly to be able to have an integrated way to allow access to plugin source from the graph
19:37:13 <be0rn> Like notes_url in nagios/icinga?
19:37:21 <be0rn> "Click here for more"
19:37:35 <Bushmills> but "click here for source"
19:37:56 <Bushmills> or "click here for whatever you have configured"
19:38:33 <be0rn> I would guess the link could point anywhere? In an operations context, it'd be useful to link to e.g. a wiki article explaining what this graph means on this system.
19:38:49 * be0rn adds a +1 to graph_link
19:39:02 <Bushmills> yes, to whatever it has been set in plugin config
19:39:31 * TheSnide writes it down.
19:39:46 <be0rn> (Sorry for hijacking the json section :-)
19:39:50 <Bushmills> like  graph_url http://goatse.com   or  graph_link http://....
19:39:59 <TheSnide> Bushmills: :/
19:40:29 <TheSnide> Bushmills: +1 for it, i'll open a new topic later
19:40:35 <Bushmills> i misspelled or is-tld'ed purposely
19:40:48 <TheSnide> oh, ok. thx :)
19:41:07 <TheSnide> so, about JSON....
19:41:26 <TheSnide> what i'm working on is :
19:41:53 <TheSnide> - state (to be able to replace munin-cgi-state)
19:42:41 <TheSnide> - an array for child elements
19:43:49 <TheSnide> - an "uri" elements, that is populated by links for the "real" website.
19:45:00 <TheSnide> - ... some standalone sql+json, that is pluggable on 2.0.x, for extra awesomeness.
19:46:46 <TheSnide> ... will be 2-fold, a munin-sql script that converts the Storable into SQL from cron. And then the vanilla munin-json daemon that reads the SQL back.
19:47:51 <TheSnide> for now only SQLite is supported, as it enables to focus on _features_. Crazy patches for any DB are welcome.
19:49:38 <TheSnide> note that the DB is fully recreated each munin-update, that's currently on purpose. Once the features rock-solid, I'll move to fully transactional updates.
19:51:12 <TheSnide> the urls are currently like that http://munin.example.com:3000/nodes?node_id=5
19:51:53 <TheSnide> with the node_id=5 part optional, and that can be replaced by "grp_id=4"
19:52:17 <TheSnide> It always returns an array of nodes, even when there's only 1 inside.
19:53:16 <TheSnide> I was thinking about making another accessor like /node/5 that is equivalent to /nodes?node_id=5 except that it only returns the node, without the enclosing array.
19:53:17 <Bushmills> doesn't look very symbolic, as in mnemonic
19:54:04 <TheSnide> i'm still thinking on how i can bridge the "path" and the ids.
19:54:30 <TheSnide> since, well. the IDs are nice for computers. but humans do like paths better :)
19:54:58 <TheSnide> each node contains a "path" attribute btw. But it isn't in the URL.
19:55:50 <TheSnide> The ugly part is that the id currently might changes
19:56:00 <TheSnide> each munin-update run.
19:57:32 <TheSnide> so, my initial idea for a bridge was "/nodes?path=my/path/prefix" that returns all the nodes inside this path prefix
19:58:51 <TheSnide> like, "/nodes?path=grp1" would return grp1;node1 grp1;node2 grp1;subgrp1;node3 grp1;subgrp1;subsubgrpA;node4 but not grp2;node5
19:59:29 <TheSnide> and neither "grp2;subgrp1;node6" as it does require a full match.
20:00:16 <pretec> Hi
20:00:47 <pretec> I prepare 2.0.20 for Debian and *wooosh* 2.0.21 is out
20:00:49 <pretec> :-)
20:00:50 <TheSnide> .. or would it be better to just accept/force wildcards ? like "/nodes?path=*sub*" would match grp1;subgrp1;node3 grp1;subgrp1;subsubgrpA;node4 ch.
20:01:00 <TheSnide> pretec: :)
20:01:17 <TheSnide> pretec: .21 is .20 with 1 reverted commit.
20:02:00 * TheSnide looks around for someone still here :)
20:03:11 <TheSnide> be0rn, Bushmills: how about a new command "node_id" that would be autogen at first launch ?
20:03:41 <TheSnide> to be able to move nodes around. It would be an MD5 or an SHA1
20:03:49 <Bushmills> i don't have a good grip on its implications at this point
20:04:01 * be0rn neither
20:04:06 <TheSnide> Bushmills: well, shoot in the dark. as I do :)
20:04:23 <be0rn> I'm much better at commenting and suggesting after-the-fact.
20:04:29 <TheSnide> i'm mostly asking for brainstorming.
20:04:42 <TheSnide> be0rn: yeah. ranting :)
20:04:51 <Bushmills> does it add complexity? does it compensate so by simplifying things elsewhere?
20:05:42 <TheSnide> Bushmills: one of the core issues is that if you more node around in the grouping, naming or whatever, you just end up moving rrd around
20:05:55 <TheSnide> ... and html, and url.
20:06:14 <Bushmills> or relink directories/files
20:06:15 <be0rn> It'd be quite some work to locate the proper rrd file for maintenance (killspike etc)
20:06:21 <TheSnide> I don't know if that is a good feature, or a PITA.
20:07:31 <TheSnide> I was thinking that "node may supply node_id". It will be used for internal stuff. Such as RRD filenames and JSON API.
20:07:57 <Bushmills> that node id could then be a directory name too?
20:08:16 <TheSnide> nope. Only valid md5.
20:08:22 <TheSnide> or sha1.
20:08:26 <TheSnide> or whatever.
20:09:27 <TheSnide> oh, it would be in the $MUNIN_DB/by_nodeid/$MD5
20:09:33 <Bushmills> a hash of what?  some hard node feature, or soft naming?
20:09:34 <TheSnide> something like that
20:10:15 <TheSnide> bonus points to have the human readable name as a "ln -s" to the MD5 one.
20:10:26 <be0rn> Ah, like /dev/disk/*
20:10:29 <TheSnide> yup
20:11:02 <TheSnide> It looks very tempting, yet i don't know if it's going to be a good idea or not
20:11:35 <TheSnide> pruning the old links might be daunting.
20:11:40 <TheSnide> or note.
20:11:41 <TheSnide> not
20:11:57 <pretec> http_loadtime is a little bit broken
20:12:43 <TheSnide> also ? /me despairs
20:13:22 <TheSnide> c0e915930853d35ef861d8327710124cfa0b38e0 did touch it
20:14:00 <TheSnide> so, i think that's it for JSON
20:14:09 <TheSnide> #topic misc
20:14:25 <TheSnide> m-c doesn't have its own topic.
20:14:45 <TheSnide> and i'm +1 for graph_link
20:15:50 <Bushmills> there may be a rat tail of additional requirements coming from it, when actually used for plugin sources
20:16:08 <Bushmills> considering that server may not have access to plugin sources on nodes the way it is
20:16:36 <TheSnide> for plugin source, i'd better consider graph_src
20:16:47 <TheSnide> inline in the stream.
20:16:52 <Bushmills> but as it is, graph_link could be a very generic facility
20:17:19 <TheSnide> graph_link is only an URL. do as you like with it.
20:17:38 <Bushmills> xactly
20:18:08 <TheSnide> I'm actually thinking about embedding some auto-POD in it
20:18:33 <Bushmills> run some javascript editor on client browser for editing plugin sources, POST them back when done :)
20:18:43 <TheSnide> to have a way for plugins to show their doc directly on the master
20:19:00 <TheSnide> Bushmills: *ehem*
20:19:24 <Bushmills> in a controlled environment, of course
20:19:34 <TheSnide> as currently the graph_info is rather limited.
20:19:58 <TheSnide> Bushmills: i'd rather not do that :)
20:20:17 <Bushmills> "do as you like with it." your words :)
20:20:57 <TheSnide> oh, the JS/POST thingy is on the node ? Then it's fine with me :-D
20:21:05 <Bushmills> i thought of that in 1.3 already. when interval graphs had no zooming
20:21:19 <Bushmills> so now the link would have to be somewhere else
20:21:48 <TheSnide> Yeah, and the multigraph links also have to be somewhere. To be able to zoom on them.
20:21:50 <Bushmills> well, a cgi url, probably
20:23:19 <Bushmills> one place could be the legend.  list of fields, internal names, etc.  would allow graphname.url to link those to urls
20:24:39 <Bushmills> for a graph_link there doesn't seem to exist a great place to bind to at the moment
20:25:40 <Bushmills> graph_category  could carry a link, but its usefulness would be limited, i'd say
20:27:13 <Bushmills> graph title above the graphs may be best candidate fo graph_link the way it is now
20:32:22 <Bushmills> best i can come up with for overview (where day and week graphs are shown for each plugin) is that when graph_link has been assigned an URL, graph titles are displayed (as links) above the graphs
20:34:10 <Bushmills> maybe allow that name configurable too. graph_link url  and  optionally graph_linkname text above graph
20:34:58 <Bushmills> after all we know what the graph name is. but we'd want to know where the link may lead us zo
20:35:00 <Bushmills> to
20:35:34 <TheSnide> yep, next to. with this icon http://munin-monitoring.org/chrome/common/extlink.gif
20:36:34 <TheSnide> ... to show that it's a unknown localtion
20:40:10 <Bushmills> hm..  "ad supported plugins"  (evil grin)
20:46:22 <Bushmills> oh, on a side note, i brought http://plugins.munin-monitoring.org/ back to utility, which it wasn't since munin went to 2.x
20:59:18 <TheSnide> ok, seems that's all folks
20:59:24 <TheSnide> #endmeetingg
20:59:25 <TheSnide> #endmeeting