Re: My GSOC todo list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Krzysztof A. Adamski wrote:
On Tue, 27 May 2008 17:51:05 -0400
Michael DeHaan <mdehaan@xxxxxxxxxx> wrote:

We need to figure out though how it might be different from other monitoring/stats based apps so that we know why we are building it --
just to not create another monitoring stack.
"Yet another stack" is actually one of the reasons. Func is so cool
that many people are using it to control all of their machines. So they
already did all certs work to setup secure connections, why should they
bother to setup "yet another stack" (possibly not so secure) just to get
some stats from the machines?

It might just be as simple as finding a simple way of letting Nagios use certmaster-certs
but is probably worth exploring. That's usually stuff for rrdtool/collectd.
Inventing the wheel again is always bad so instead I would like to
focus on creating "wrapper" modules that are able to get stats from
other applications (like nagios plugin) and use Func only as transport
layer and API for easily creating customized stats applications.

Func's generally not good (right now) for providing a channel in the backwards direction, it needs to ask for data. This may be interesting as different data might have different reporting frequencies, etc?

So there are 3 advantages:
- no need to setup another communication link between computers
- it's more secure than most stats applications
- cool API for creating apps that use statistics informations (like
integrating it with some web application)

func-stats should only be example application, just like func-inventory
is.

Apache configs are kind of hard to model, what do you have in mind
there?
Using templates, set in local module configuration files or pushed in
the "copyfile" style (your idea). You have suggested using Cheetah
templates which sounds reasonable.

Yep, that way it could be generic for more than just Apache.

Something like... (?)

func "*.example.org" template /tmp/foo.tmpl /etc/foo.conf --vars="zipcode=12345 favoritecolor=blue"

And that would probably be even cleaner from the API.

Doing that where local files could also be used to provide metadata to the template that varied by the system
would also be pretty cool. Maybe:

func "a.example.org" copyfile /tmp/fooA.meta /tmp/foo.meta
func "b.example.org" copyfile /tmp/fooB.meta /tmp/foo.meta
func "*.example.org" template --source=/tmp/foo.tmpl --output=/etc/foo.conf --metadata=/tmp/foo.meta

I'm sure we can probably think of a better/cleaner syntax for how that might work.

If you stored the metadata in YAML and/or XML or some other serializable format, that could be pretty interesting and you
could possibly even share metadata between various files.

There are probably a lot of other interesting ways to expand on that too...

_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list

_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list

[Index of Archives]     [Fedora Users]     [Linux Networking]     [Fedora Legacy List]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux