> What I was thinking was that you would tell augeas to > edit "/tmp/func-test/etc/ssh.conf"
Currently augeas maps the system tree or a chroot with AUGEAS_ROOT Every file recognized is the sys tree with a valid lens is loaded. It's not possible to map a specific folder or file. Louis 2009/2/24 Adrian LIkins <[email protected]> > 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 [email protected] https://www.redhat.com/mailman/listinfo/func-list
