Michael DeHaan wrote:
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?
I've been trying to figure out a good way to handle the per
distribution/os kind of things. Don't have a good idea yet though.
A per module config file would probably help. I think we need to figure
out a way to make better use of the module/method version
info as well.
Maybe some sort of capability exchange between overlord and minion, so
they can negotiate api versions and whatnot. ie, overlord
could say check what version a module/method is before calling it, if it
were important for compability. Or the minion could answer
differently depending on what version of overlord was talking to it. I
don't think either of those should happen by default, but it's nice
to be able to do it in cases of "oh crap, that method change breaks
clients < v12.34.56".
For the above case, and the distribution/os case, I think in general the
best thing to do is set config options, and change change behaviour
based on the config options. So this ties into the per module config issue.
Adrian
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
