Louis Coilliot wrote:
> Unified diff are usually a little easier to deal with, if possible
("diff -u" or just "git diff")
Yes, sure, sorry, I've seen this afterwards by looking at posts about
patchs on augeas and func lists. I'll do this now.
> Maybe the test scripts could just install some example config
> files to /tmp and not have to set the an AUGEAS_ROOT at all?
Well, it does install config files in /tmp.
For AUGEAS_ROOT, there is a solution:
I call the class Augeas() in augeas.py, and it is possible to set the
root there:
def __init__(self, root=None, loadpath=None, flags=NONE):
...
What I was thinking was that you would tell augeas to edit
"/tmp/func-test/etc/ssh.conf" instead
of augeas_root+"/etc/ssh.conf". Does augeas rely on the file path to
determine how to edit the file?
(aka, somewhere augeas knows "/etc/ssh/sshd_config" means to use the
bits that understand ssh
config files). If so, is there a way to override that (alter the filter
on the lenses defination,if I understand
the nomenclature correctly).
Lack of any minion side object persistence or state makes some of
this difficult. So either an option
to every arg, or a config option might be best.
The problem is that there are more and more options to pass to the
methods in the func augeas module:
set(self,entryPath,param='',pvalue='',hierarchy='/files')
I could also add options like augeasroot and backuptype
(newfile/backup/overwrite), but then when you want to set only the
last option in the list, you need to set also all the options before
(it's ordered, not labeled)
This is not possible with a method in func:
def test(arg1,arg2,arg3='testarg3',arg4='testarg4'):
print arg1," ",arg2," ",arg3," ",arg4
test('pim','pam',arg4='louis')
Or did I miss something ?
Thats a limitation in the func method marshalling. Kind of lowest
common denominator of what xmlrpc can
express, and how the python methods can be called. One option is to pass
all the args in a dict, and let the
minion module figure it out (as opposed to the method demarshalling code
figuring it out). I'm not a big
fan of that approach though, since it tends to be difficult to
document/introspect.
Let me know if you think it is best to add options anyway.
Another option is a conf. file like /etc/defaults/func with something
like:
augeas_root=/tmp
augeas_backup=overwrite
But this is ugly and my little module gets intrusive.
One option might be to add a test specific module config file. The
func minion modules have support for
a per module config file that you could make the module support, and we
just drop one with the augeas root
in place when we need it and clean it up after the tests.
Do you know another way to pass some persistent parameters when calling
func.overlord.client.Client() ?
No way to do that currently. Could be useful though.
> Whats you'r thoughts on the module name? we could sub module it and
make it config.augeas.*.
The sub module with this name config.augeas is fine ! I agree with you
that it's more explicit (that is better than implicit...)
And people don't really need to know about augeas to do basic actions,
like:
change 'parameter' with 'value' in 'conf_file'
Because the '/file' hierarchy is the default and is masked in the func
module.
Raphael Pinson who showed augeas at the fosdem a few days ago told me
that augeas was a tool for programmers, not for operators.
But func should be:
- crazy simple to understand
- crazy simple to use
(especially with the WebUI frontend symbolic)
I plan to provide some actions with symbolic to operators, with a
strict perimeter for actions and no sysadmin/scripting skills. I
could not do this with SSH+scripting.
So I want to mask the inners as much as possible.
Anyway if people then need more power, they are free to dig with the
xpath expressions.
If you're OK with this I'll change the name of the module.
Yeah, name change sounds fine to me.
Adrian
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
