Michael DeHaan wrote:
makkalot@xxxxxxxxx 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
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
FWIW, this subject should really be "facts and critera" now -- we are
not focused on "ORM" things.
--Michael
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
