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
