On Tue, 22 Apr 2008 15:32:54 -0400
Michael DeHaan <mdehaan@xxxxxxxxxx> wrote:
> > The problem with async calls is that GSoC coding begins at May 26
> > while there where at least 2 people asking for that on the IRC in
> > last couple days. If it's not illegal, I would be happy to start
> > working on this even before offical coding begins. What do you
> > think?
>
> Perfectly fine with me. We can consider that part of the GSOC stuff :)
Ok, great, i will start working on that as soon as i have some free
time..
> Kind of like inventory() ? But maybe stats() ?
>
> Embedding something like range/display/gauge information (value is 7,
> min is 0, max is 10) might be useful
> for helping to draw gauges.
Exacly. But i think we will need 2 methods, one for numerical values
and second for this additional informations. stats() could be good for
the first one while something like plot_info() could return the last.
>
> > The idea is to create architecture similar to inventory. I would
> > like to create a simple tool that will work similar to
> > func-inventory (being an example of using this API).It will query
> > modules for data and use rrdtool to store them and create some
> > plots.
>
> ++.
>
> Denis, any thoughts on the above and any piece you might like to work
> on as part of this
> since you also expressed interest in stats? Maybe one of you could do
> backend tasks while
> the other looks at some of the frontend, etc?
I think maybe func-stats could be integrated to FuncWeb. Plots
generated by rrdtool could be displayed and organized there. I'm not
sure if this is something you are are interested in..
Also, i think we could try creating some "wrapper", similar to
NagiosCheck module. I'm not yet sure if it's doable and if it makes
sense but there are some existing solutions for gathering statistics and
they have their own modules which someone would like to use with func
(like, he likes modules from some other tool but wants to reuse func
secure infrastructure instead of using native one). Any thoughts on
that ?
> > First one is the simplest but it's not scalable.
>
> Why do you not think it's scalable?
It's not scalable for storing more informations than the port number,
like i described below:
> > We may possibly want
> > to have some more special configuration informations associated with
> > minions and using filenames for all this won't be good idea.
> >
>
> Indeed, if we /do/ have a need for special per-minion configuration
> options, we will have a need for that, though
> that seems independent of this and could be done separately as
> required by the use case.
I agree on that it can be done separately.
> > - Apache httpd module:
> > Module should allow some basic Apache httpd configuration, with
> > possibility to quickly add/remove additional virtualhosts by
> > creating directory, setting proper permissions and dropping config
> > file in /etc/httpd/conf.d/
> >
>
> Do you intend on modelling all that is in the virtual host section?
> This seems like it could be served
> by copyfile and later doing some configuration management (like "RRS"
> on the Wiki) on top of Func
> if we want to go there.
No, it's not even possible to manage all aspects of Apache
configuration (since it can be extended with modules). We could use
some template, configured in local configuration file (which would be
done first). It is quite common that all virtualhosts on a server has
similar config and the only difference is in their URL and path on the
system. Administrator could create template file, similar to this:
<virtualhost {HOSTNAME}>
DocumentRoot {DOCROOT}
ServerNane {SERVNAME}
...
</virtualhost>
And then just pass proper values for template variables when calling
the module. You may not believe me but this can be very useful :)
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
