Krzysztof A. Adamski wrote:
I'm working at adding support for per-module configuration files. This
could be used to set default values for some options or change module
behaviour based on the distribution used (proper default configuration
files could be added by packager when doing func package).
We want the modules to be still easy to develop so it's important how
it will look like from module writer perspective. I think that using
func.config module would be the best idea (i could write wiki page
about that module). Nothing changes if you don't need configuration
file but if you do, here's how it looks:
import func_module
import func.config as config
class Example(func_module.FuncModule):
# Update these if need be.
version = "0.0.1"
api_version = "0.0.1"
description = "An example module."
class Config(config.BaseConfig):
option1 = config.Option('default')
option_list = config.ListOption('')
def show_option1(self):
return self.options.option1
def show_list(self):
return self.options.option_list
So we have to import additional module and then create Config class
inside of our module which should contain list of expected options. We
can use self.options.OPTION_NAME to get value of OPTION_NAME.
Configuration file shoud be stored in
/etc/func/modules/MODULE_CLASS_NAME.conf
so in above example it is:
/etc/func/modules/Example.conf
Any comments ?
This looks good to me. So the intent here is to be able to put a config
file on each remote machine that describes how the module should behave,
as opposed to having this config file on the overlord. Correct?
The above looks fine to me, though we just need to be sure that if the
config file is not present, that the module still works using the
default values.
Can you give some examples of where you think this might be useful?
Fixing the implementation of filetracker to use this might be a good
start (this is a tripwire-like system, that allows watching diffs of
files via func-inventory).
(BTW, before we get too far into this, one thing I think we still need
to do on the async implementation is to create that overlord side
configuration file that gives a list of which methods need to be called
async for the 'call' method).
_______________________________________________
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
