seth vidal wrote:
On Thu, 2008-10-09 at 10:32 -0400, Michael DeHaan wrote:
seth vidal wrote:
On Mon, 2008-10-06 at 17:39 -0400, Michael DeHaan wrote:
Michael DeHaan wrote:
It would be nice to have a way to issue offline orders to minions so
they could check in when they come online (via XMLRPC) and then see if
they have any orders.
This is the other mode of communication we would like to support in
order to enable Func to replace OSAD in Spacewalk.
For example, "this node should yum update the next time I see it" is
different from "this node should update now if it's online".
Anyone have any thoughts on implementations?
--Michael
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
To elaborate, basically with what we have here and also the new cobbler
"config file templating" feature, we have the makings of a much easier
to understand config management tool, all in Python, and all very easy
to understand. This could be the beginings of "RRS" (remote rocket
surgery) built on Cobbler+Func. (See also recent Cobbler integration).
We just need a way to address offline nodes, basically.
Offline commands are fine if you don't expect some sort of response from
the command, right?
We'd need something more or less like this:
for each host
if ping host
do command
else
store command and retry
the retry trick only works well if we have another daemon running that
stores the commands and the responses, I think, I guess we could do it
with a regularly scheduled cron job to look for unrun jobs but....
-sv
I was originally thinking what if the Func minions just pull from the
queue? The only problem with that is we don't have a programatic easy
way to look at all the results together as we do with async today.
That would probably be harder and maybe not as useful.
It would be nice if it worked using the existing async style API's.
What's the model we're targeting with regard to interactivity? We don't
really want highly interactive interfaces but do any of our modules
right now do anything more than just issue commands and get result
codes/returned data?
None of them are interactive.
We could have the daemon store both commands and results and wait for
them to be viewed.
something like:
/var/spool/func-queue/
hostname/commands/0/1/2/012345
/results/0/1/2/012345
Currently we have the bsddb stuff for storing results. Results go away
after about an hour. We'd obviously want to bump this but I think we
just have to add an orders queue and a way to make the overlord know to
retry and a way to save those orders (another bsddb db would be simple,
if not human editable). This could really just be cron, I think.
Or at this point are we better off just using xmpp?
It does feel a bit like inventing an email/bus type deal, but I think we
have enough differences.
The key is to just do something simple.
For some sort of "1.0" concept, getting off of bsddb might be nice.
-sv
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
