On Tuesday 13 January 2009 06:18:02 pm 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.
I liked the idea of having a separate structure for calling facts. I read the
facts API a little bit and we may use sth like them having a facts directory
and putting the stuff under it. Examples are better :
/facts
__init__.py
cpu.py
And we may have in cpu.py :
class CpuOptions(SomeParent):
def get_temperature():
#return some value
get_temperature.global_name = "temperature"
We will have a loader which can register the global names (which can be
thought as tags) and it will register also the full_path things as we do in
current minion modules. (Honestly dont see the difference with current module
loading process ?)
After we can call it 2 ways :
c = Client("*").filter("temperature" = 55).do_some_stuff()
or directly :
c = Client("*").filter("facts.cpu.get_temperature" = 55).do_some_stuff()
>
> 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'", ...)
Programatically i dont like that syntax, the above one (my example) seems to
me more modular and clean and i also want to be able todo things like :
c = Client("*").filter("facts.cpu.get_temperature" = 55).exclude("os"="f8")
to have chaining options like that, bu i dont know if it is possible :)
> 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.
+1
>
> Finally (4), we need to look into developing more object oriented (and
> stable API) abstractions around objects and interactions.
Exactly
> 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.
Agree, we need some cool abstractions for better API.
>
> 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.
I'm ready to help when have time, i liked the ideas especially facts thing ,
also want to practice some API design things :)
>
> 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
