Krzysztof A. Adamski wrote:
On Tue, 22 Apr 2008 11:40:08 -0400
Michael DeHaan <mdehaan@xxxxxxxxxx> wrote:
-- Making async command line calls work, and general cleanup of
async/copyfile/etc in general
This is part of my proposal.. We have discussed async calls on the IRC
some time ago. I think both mpdehaan and alikins took part in the
discussion. I did some notes to my GSOC application:
d) Async 'call' cmd_module:
The module should take a optional (--async) argument that will force
it to take advantage of async API. User should be able to select if
he wants to wait for results (--poll, default behavior) or he will use
--jobstatus argument to check the status himself (--nopoll). It
could be further enhanced to automatically use async call for some
marked methods (like yum.update()).
Sounds good.
My thoughts:
Make --async optional (default noasync), make --poll the default if
--async, do not add a --nopoll (assume nopoll).
I think we had talked about storing a list of methods that should always
be called async in /etc/func (how about /etc/func/async_commands)
and that file could be used to make "call" go async automatically for
commands that need it.
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 :)
As for copyfile improvements, i would like to create some minion module
that is able to create some temporary files. This module should have,
at least open(), close() and append() methods. open() would create the
local file (possibly with some temporary filename); append() would be
called in a loop each time overlord reads some data from the local
file. Finally, close() would finish the operation. Overlord could use
this methods to send files in chunks.
You could do something a bit like Firefox does -- save the file
originally as a ".part" and move it back
when you are done.
That prevents needing temp directories which are sometimes hard to clean
up after.
-- The statistics gathering ideas in the GSOC proposals that had
similar ideas and can probably be divided up into backend/frontend
parts?
I think we should think about some general API (like some methods
that should be provided by a module) statistic modules should use in
order to report some informations. In addition to just returning some
values, it would be good to provide informations that could then be
used by some plot tools (like title, units etc).
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.
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 makkalot had the most interest in doing FuncWeb stuff, and I
believe pleple wanted the proxy issue?
I was interested in working on port issues, not really proxy stuff. I
would like to make it possible for funcd (and possibly also certmaster)
to listen on different ports.
We can leave the proxy() call implementation to Steve Salesvan then, or
one of us -- we think we have
some relatively simple ideas on how to implement it.
It should be possible to use different
port number on each minion and globing should still be working. In
order to achieve that, we have to store port information on the
overlord. I've proposed three ways:
- storing port information in the filename, like:
{hostname}:{port}.(cert|csr|pem)
I think I like the above.
- using dedicated file for special configuration, like:
{hostname}.conf
- using dedicated directory with individual files for each additional
setting, like:
{hostname}/port.conf
{hostname}/some_other_stuff.conf
First one is the simplest but it's not scalable.
Why do you not think it's scalable?
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.
We wan't func working on big setups, like thousands of minions. This
means we will have a lot of files in the cert directory. This may be a
problem for performance so using dedicated directory for each minion
could be better (we could place cert files there too -this won't be
backward compatible but we can work around this..).
Other things I'm going to work as part of GSoC program include adding
support for local modules configuration files (on minions) and some new
modules:
- users, groups and hosts configuration modules:
just modules for managing user groups and accounts and /etc/hosts file
+1
- 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.
- Cron and at modules:
Modules allowing remote configuration of cron and at services.
Sounds good.
_______________________________________________
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
