Oh, agreed. You'd need some sort of triggering language(?) which
would let you set the prerequisites (including time-based), and the associated
actions.
maybe not.
below is an example of how in our system we manage the life cycle of files.
ignoring the baroqueness of teh syntax, it precisely allows you to manage what happens
to files
define Media cve_fsm {
initial state state0 ""
arc state0 inplay transmission(%file, sighted)
arc state0 registered repmgr(numbat, %file, registered)
state inplay "attempt made to send file"
arc inplay registered repmgr(numbat, %file, registered)
state registered "file registered with numbat repmgr"
arc registered active repmgr(numbat, %file, stable) &&
repmgr(ningbing, %file, n) >= 1
state active "file usable"
arc active ontape1 tape(%file, n) >= 1
state ontape1 "on tape at least once"
arc ontape1 ontape2 tape(%file, n) >= 2
state ontape2 "on tape twice"
arc ontape2 dormant repmgr(numbat, %file, n) == 0
final state dormant "quiescent"
}
what i like about this is:
1) the state names (and the comments in "") are meaningful to the user and are labels in reports and queries
2) the "triggers" are not so much triggers as predicates; in an arc statement, when the predicate is true,
the FSM traverses the arc (from first arg to second arg).
3) it leaves unrestricted how progress is initiated. for some of these predicates, there are existing
processes which will cause progress to occur without any overt action. for others, the tool
that computes the state knows what predicate needs to become true in order for teh FSM to progress
towards the final state, and can initiate that action. for example, if a file is "registered" but can't
graduate to "active" because there isn't a copy on the ningbing cluster, then we can send a copy,
and eventually that predicate will be true and we'll be active.
4) none of these FSMs are big, or if they are, they are almost all linear. they have been relatively easy for
users to grok, especially if statistics etc use the (user chosen and meaningful) state names.
although i've not worked the details, i think this could be easily adapted to configuration changes
(although may be not all).
----
Andrew Hume (best -> Telework) +1 732-886-1886
[EMAIL PROTECTED] (Work) +1 973-360-8651
AT&T Labs - Research; member of USENIX and LOPSA
_______________________________________________ lssconf-discuss mailing list lssconf-discuss@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
