Re: [Clockwork-developers] Implementation of a decentralized schedule
Status: Planning
Brought to you by:
jlouder
|
From: Joel L. <jo...@lo...> - 2002-03-03 23:12:20
|
+- On Monday (1/14/2002 10:40) Charles Brian Hill <br...@do...> Wrote- | When you have some time, let's (all) continue to bring up the pros and | cons of both approaches. The best way for us to determine a course of | action is to fully understand the problems we might encounter when we | implement them. The more we understand the question, the better the | answer we'll give. It's been several weeks since we talked about this, but I hope it's not too late for me to put in my two cents. Here's what I see as the advantages of both the centralized and decentralized schedule: CENTRALIZED: ------------ good: * Management software is simpler because the entire schedule is in one place. * We already understand a half-decent model for this type of system. bad: * At least one system has to run the scheduler. Probably more than one if you don't want a single point of failure. In a large schedule, these would need to be dedicated systems, adding to the overhead of the scheduler. DECENTRALIZED: -------------- good: * Low/no overhead: you can run a schedule without dedicating any systems to be "the scheduler." bad: * Updates to the schedule would have to propagate to individual nodes. * The management GUI would have to poll (or subscribe to) lots of systems to get an idea of the current state of the schedule, which would probably result in a delay between starting the GUI and looking at current data. * Multicast IP: I don't know anything about it, and some users might not be wild about being forced to use it. * We don't have a well-understood model for this type of schedule, so we won't be able to learn from someone else's mistakes. If you see something I missed, please reply. I hope Brian's offer to consolidate and post the list is still good. -- Joel |