[email protected] wrote:
Hi,
...
This came up on IRC and I figured it would make sense to share some
further plans that Adrian and I were discussing.
Namely, we intend to write a minion module that serves up "facts"
(similar to the idea behind facter, but probably not the same thing, in
all honestly I haven't explored it enough to comment one way or the
other yet -- main goals is simplicity and suitability to func).
It is important that any module should also be able to call directly
into this, so we need to ensure that modules can call modules. Right
now that's /not/ so doable.
Sample facts might be thinks like "facts.os.release" or
"facts.cpu.temperature" ... and that infrastructure itself is probably
modular in it's own way. This seems to imply a seperate module loader
just for facts, we don't want to cram everything into one facts.py and
the existing modules are not structured well enough to be reused in this
way.
Step two is to implement the critera feature, in which when asking a
node to do something, we pass down the critera. For example,
Client("*", critera="facts.os.flavor =='fedora'", ...) and so forth
(syntax here is /not/ important and I don't want to get caught up on
this now). This needs to be passed down with each call so it will not
require two calls to get the data and then see which ones to send the
command to -- this is for efficiency reasons and to also make sure it
works with delegation. (As a sidenote, this syntax sucks for admins,
I'm thinking more in terms of enabling new applications at this point,
though this is something we also need to address.)
Step three is to make sure that the services can be overriden based on
OS. Right now we have a "service.py", but what we really need is to be
able to have directories so we can have things like service/windows.py"
(yes, you can infer from this that multiplatform Func support is an
eventual goal, better multi-distro support already is) to override
classes based on OS. Some modules may choose to /not/ do this and may
instead just query facts to decide how to differentiate themselves.
Finally (4), we need to look into developing more object oriented (and
stable API) abstractions around objects and interactions. This may
imply classes like "Service" and "Package" and so forth. Ultimately the
module API is probably going to be fairly loose and free (since we need
to ensure backwards compatibility and can't muck with it), but the
higher level API abstractions would be where we'd enforce a design like
we'd like to see it, and the low level modules would be allowed to
change as we'd like. The hardware model is a good example of where the
APIs just return a largely unstructured (sic) datastructure mess and we
need to do something to make them more usable in a
cross-distro/cross-platform basis. This is going to require some
not-so-fun modelling/translation and I'm not ultimately sure where we
end up -- but it needs to be done if we want to address non-homogenous
infrastructure in sane ways.
Perhaps that's a bit parentethical and complex, though I plan to have
something implemented WRT this in the coming weeks -- currently I'm
sidetracked a bit with some Cobbler things though I want to find some
time to see these through.
Ultimately the "facts" type implementation will be useful to various
modules who want to query data regardless of whether folks find much
need of criteria filtering.
--Michael
_______________________________________________
Func-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/func-list
