Forwarding to list...
--- Begin Message ---
Krzysztof A. Adamski wrote:
On Tue, 22 Apr 2008 15:32:54 -0400
Michael DeHaan <mdehaan@xxxxxxxxxx> wrote:
Not sure if you ment to, but this arrived off-list. Please forward this
if you don't mind :)
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.
Works for me. You would also only need to call plot info on one node (or
could
reference that info from the locally installed source without calling
via the Client API).
Could also be a file in /etc even
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..
I definitely see a FuncWeb with lots of tabs for different modes across
the top.
'stats' is clearly one of them. 'virt' is probably another.
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 ?
Sounds like a good idea to investigate what we can mine for free,
absolutely.
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:
Ok.
I still think you can solve the NAT problem by making the NAT box a
certmaster and using
a proxy, but we need to do configurable ports anyway (just because
hardcoding is bad), so I think
that's reasonable.
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 :)
Having something like a copyfile API that pushes and renders remote
Cheetah templates
could be interesting.
--Michael
--- End Message ---
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
