Hi Andy: This is very exciting! The biggest challenge is scalability.
Current planners work fine for smaller problems (although sizes may
still be useful in a particular context). We also have a project on
reconfiguration planning for migrating a system from one configuration
to another without violating safety properties (introducing security
breaches or disrupting mission-critical services). We are developing a
scalable system, improving upon SAT-based ideas of Selman and Kautz from
a while back. -- Sanjai
Andrew Hume wrote:
following the hours of turgid discussion at LISA, i have been
dwelling
on the issues of deployment/rollout of service changes. in particular,
how we should think of this as a separate and orthogonal issue
to that of what needs to be done. so i decided to test the separateness
by working on a local (real) problem, which i present in simplified form.
we have 4 nodes, each with 4 tuners. we have a set of 11 channels
we wish to record without loss. in this scenario, how do you reboot a
node?
obviously, for each non-idle tuner on that node, you start recording that
channel on another tuner, and then idle the first one. after a while,
you should have all tuners on the desired node idle, at which point,
you can reboot.
now, we could all write simple programs to do this, i suspect.
but i wanted to see if it could be done mechanically, that is, by some
sort of "planning" software. of course, this is part of AI, and therefore
suspect, but i gave it a go. i'll forgo the war stories but eventually
wound up with SGPlan5 (ver 2.1). the problem description, basically
75 lines of static model description and 5 lines of configuration, was
straightforward to generate, and given a random assignment of
channels to tuners and being ask to reboot nodeB, it generated
a correct plan:
0.001: (RECORD C12 TUNERA1) [1]
1.002: (RECORD C7 TUNERA4) [1]
2.003: (IDLE C12 TUNERB4) [1]
3.004: (IDLE C7 TUNERB2) [1]
4.005: (RECORD C59 TUNERD4) [1]
5.006: (IDLE C59 TUNERB1) [1]
6.007: (BOOT NODEB) [1]
apparently, channels 7,12,59 were being recorded on B,
and it went off and started them elsewhere before the reboot.
despite issues around teh fragility of teh software, i am encouraged.
and the requirement of the channel being recorded elsewhere was done
in a clean way:
(:action IDLE
:parameters
(?ch - Channel ?tuner - Tuner)
:precondition
(and
(recording ?ch ?tuner)
(exists (?t - Tuner)
(and (not (= ?t ?tuner)) (recording ?ch ?t))
)
)
:effect
(and (idle ?tuner) (not (recording ?ch ?tuner)))
)
forgive the syntax, but its fairly straightforward, and i love the way
i can state as a precondition exactly what i want: that the
channel is recorded elsewhere. note that the requirement of
teh tuner being on another node is not needed here, but is
included in the definition of BOOT:
(:action BOOT
:parameters
(?n - Node)
:precondition
(not (exists (?t - Tuner)
(and (on ?t ?n) (not (idle ?t)))
))
any comments? has anyone else tried this approach?
any traps ahead for me?
----
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
--
Sanjai Narain, Ph.D.
Senior Research Scientist
Information Assurance and Security Department
Telcordia Technologies, Inc.
1 Telcordia Drive, Room 1N-375
Piscataway, NJ 08854
732 699 2806 (T)
908 337 3636 (M)
[EMAIL PROTECTED]
_______________________________________________
lssconf-discuss mailing list
lssconf-discuss@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
