Adrian Likins wrote:
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.
One slight problem with that stuff is it's a call that has to be made
before you make the call. However if we could somehow be very clever
and get a copy of that from calls to a /local/ invocation of those
modules, that wouldn't be so inefficient. However if asking for
details about a remote method it seems to be exactly what you want,
because there could be versions of individual modules.
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".
Yeah, this could be stored in as second global config file even, that
way we don't have to query the RPM for it. (We can't assume func is
installed by RPM). /etc/func/version for that, maybe, as the RPM will
want to override it.
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
