Adrian LIkins wrote:
makkalot wrote:
********* CAUTION A VERY LONG POST ********************
Func Facts :
What is it ? The Facts are modules like minion modules but a little
bit different. Facts are like variables of database tables.
name,temperature,kernel_version etc.
Why to need facts ? The main idea behind facts is to be able to send
queries to minions like you do to database or ORM. Example , 'run
update method on
machines which are f9 >= ... You can do that with current minion
modules of course but you have to send at least 2 queries to your
minions. Another idea behind fact is to do more things with less
connection hits.
Python API :
To use Func Facts you can use OverlordQueryProxy (i dont like the
name if you have better please tell), as it name says it is a proxy
object which acts like
Overlord and a little bit more. When writing the facts code i didnt
touch the Overlord class because it is already overloaded, and i
think that should be
the future behaviour of new added bits to func. Keeping Overlord as a
little bit abstract may be a good idea. Examples are better:
Subclassing the Overlord class is probably a good idea. At least
for the common cases, it wouldn't hurt
to have some canned subclasses ready to use.
I'm drawing a blank on better names at the moment.
Why not just use the Overlord("*") connection we have now? Basically
that just represents the connection to the modules. Any concept of
"facts" would just be like any other func module, not really any
different...
#using object as Overlord In [1]: from
func.minion.facts.overlord_query import OverlordQueryProxy
In [2]: fc = OverlordQueryProxy("*")
In [3]: fc.echo.run_string("func blips")
Out[3]: {'localhost.localdomain': 'func blips'}
#to see the availible fact methods i have written a little minion
module to show them ..
[root@fedorabig func]# func "*" call fact list_fact_modules
{'localhost.localdomain': ['hardware', 'fact_module']}
[root@fedorabig func]# func "*" call fact list_fact_methods
{'localhost.localdomain': ['hardware.cpu_model',
'kernel',
'cpumodel',
'hardware.kernel_version',
'cpuvendor',
'hardware.run_level',
'hardware.cpu_vendor',
'hardware.os_name',
'runlevel',
'os']}
[root@fedorabig func]# func "*" call fact show_fact_module "hardware"
{'localhost.localdomain': {'description': 'A modules that supplies
hardware facts',
'name': 'hardware',
'version': '0.0.1'}}
[root@fedorabig func]# func "*" call fact show_fact_method "runlevel"
{'localhost.localdomain': {'description': 'Shows the runlevel of the
system',
'name': 'runlevel',
'tag': 'runlevel',
'usage': 'Can be used with all keywords'}}
Facts are more of a programatic thing, so the API is more interesting to
me than just showing something via call.
I'm not sure why English strings would be of that much use in a
programatic context.
Sounds reasonable API to me, mirrors the normal func module/method
introspection.
The facts are methods that mostly (at least now) doesnt accept any
arguments, so if you want to see the value of an existing fact just
[root@fedorabig func]# func "*" call fact call_fact "runlevel"
{'localhost.localdomain': '5'}
What would be an example of fact methods that need args?
The ORM queries:
When Michael mentioned about facts idea i wanted to have something
that can let me do some crazy chaining queries so i now i should
explain a little bit
the query stuff of the facts. With func facts you can run very
complex queries. But lets go from easaier to hard :
In [3]: fc = OverlordQueryProxy("*")
In [6]: result=fc.filter(runlevel=4).echo.run_string("Hey func")
#run that on machine that has runlevel 4
In [8]: fc.display_active(result)
Out[8]: {}
To simplify:
fc = Overlord("*", [other options])
rc = fc.filter(runlevel=4).somemodule.somemethod()
Func's philosophy is making things very simple to both API scripts and
developers, and with the above stuff it looks rather complex and
unwiedly at this point.
Just my two cents.
--Michael
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
